Hi folks.
When I create a new item ie save from photoshop to a folder, i dont see the file appear in the folder if i have the folder open already. I have to press F5 to refresh for it to appear.
Is there a setting for this?
Normally dopus listens for changes to local and network folders and refreshes the lister contents accordingly. However occasionally when an error occurs - filesystem change-sensing starts failing across all listers and tabs. Only restarting dopus - and sometimes multiple times at that - manages to fix that.
I don't remember having experienced this behavior before 12.2 and not sure if the OP has the same problem in mind, but I'm interested if anyone else has experienced.
Please see this guide:
I'm at my wits end fighting the randomness of this problem. After following the tutorial Leo mentioned:
- Dopus gets notified of all changes and all paths match BUT the listers aren't updated.
- Even restarts and logoffs don't seem to fix it. I need to restart dopus up to 10 times for it to start properly refreshing.
- When renaming in opus - name stays the same although file is renamed
- Windows explorer refreshes immediately when renaming in opus
- Renaming in windows explorer notifies dopus but it still won't refresh the lister
This happened occasionally when dopus crashed and was recovered but it was never so bad before the latest beta.
Happens intermittently when I have many listers with many tabs open (7-8 dual listers with 7-8 tabs per side). If I close all listers but one and restart - it starts working again.
Just a guess, but having ~128 folders open, especially if they're ones which are slow to check (e.g. network drives), might mean there's so much overhead sending and sorting change notifications that some are being dropped, or taking a long time.
What's the CPU usage like?
What kinds of folders are affected; are local folders affected?
What does the debug output look like, vs the paths shown in the folders? Are the paths and names the same, or are there differences? (e.g. Does the debug output reference alternative paths due to symlinks/junctions, or short 8.3 names? Opus should map between them, but it's worth knowing about if those are involved as it's part of the process that might be going wrong.)
Is there a lot of background noise in the change notification logs? i.e. Thousands of events per second from something else on the system that is flooding the logs. (Some background noise is normal, as there's always something going on, but if the log is scrolling non-stop so fast you can't read it then it might be a problem, especially with so many folders open at once.)
95% of them are local folders, not symlinks, and yes they are affected.
The remaining 5% are network folders which link to an always-on server over a gigabit LAN connection.
Debug paths are correct and match the actual folders being changed. Not alternatives .
Debug paths are full filenames, not 8.3 (probably because no symlinks were involved).
No background noise either. Debug is generated only when there are filesystem changes most of them user triggerred.
CPU usage is negligible - under 3%.
That sounds fairly normal so it probably isn't due to a flood of events overloading things.
Have you tried with antivirus disabled? Checking change events can involve inspecting the changed files (e.g. to see if they are a file or a folder) which could conceivably trigger antivirus to scan a large archive/exe, and get stuck or become very slow, perhaps.
It might also be worth generating a few dumps while the problem is happening, which we might be able to see to see if one of the change notification threads is getting stuck somewhere so that further events are not processed. Here's how to do that:
While it's happening, please go to Task Manager, then the Details tab, right-click dopus.exe and select Create Dump File.
Do that 4 or 5 times, and it should create something like:
C:\Users\<username>\AppData\Local\Temp\dopus.DMP
C:\Users\<username>\AppData\Local\Temp\dopus (2).DMP
C:\Users\<username>\AppData\Local\Temp\dopus (3).DMP
C:\Users\<username>\AppData\Local\Temp\dopus (4).DMP
C:\Users\<username>\AppData\Local\Temp\dopus (5).DMP
The files will be large, but compress well.
If sending more than one file, using the 7z format instead of zip will give a much reduced size. You can do this via the Archive Files button in Opus.
Please zip or 7z the files and email them to crashdumps@gpsoft.com.au (it's best not to post full dumps publicly to the forum).
I've posted 3 live dumps from over the last few days when I experienced this behavior.
Mail title: Dumps related to T25621