Opus should detect changes to folders automatically, but there are some things to check first:
Fully exit Opus and restart it, in case the problem is with the Windows change-notification system losing track of the request from Opus to listen to changes on the drive(s) in question.
(Note: Do not just close & re-open all your Opus windows; that does not exit the program by default.)
Go to Preferences / Miscellaneous / Advanced and make sure no_external_change_notify is set to False (which is the default).
Check that Windows Explorer is able to see changes on the same drive, when you make changes using Directory Opus or something else that isn’t Windows Explorer. If not, the drive may not be sending change notifications at all (or may be sending them incorrectly; or may be sending them, but very slowly as in the Samba case below).
Explorer needs to be looking at the folder already, before the change is made, when you do this test, so it can see the change as it happens. (If you make the change and then open or navigate Explorer to the folder, the test is not meaningful; it’s like pushing F5 to force the folder to be re-read after making the change, which isn’t testing that change notifications work.)
If it’s a network drive, make sure Preferences / File Operations / Options: Detect external file changes on network drives is turned on.
If it is a network drive on a non-Windows system then it is probably shared using Samba at the other end. Because most Unix/Linux filesystems do not support change notification, many versions of Samba implement notification by polling the drive every X seconds, where X is configurable on the server but defaults to something quite large, sometimes a couple of minutes. This means you often don’t see changes made to Samba network drives for a long time, if it was something other than Opus which made the change. Very old versions of Samba do not support change notification at all.
If it is a NAS device or similar (e.g. router-attached storage) from a vendor like Synology, make sure it has the latest software and firmware installed. This has fixed many problems for people, sometimes only affecting some programs and not others. It continues to fix problems even on newer devices. (Note: Sometimes there are up to three things to update: Firmware on the device itself; software on the device; software/drivers on the PC side. Not all devices have all three and some may combine things into a single package/installer. Check the manufacturer’s downloads area to see what is available.)
If NTFS junctions, softlinks, mount-points, subst, etc. are involved then they are worth mentioning. Opus should detect changes through them but they can still complicate the situation and are worth keeping in mind.
If the problem only happens on a certain drive, or below a certain folder, or type of folder (e.g. a Library, or a Library pointing to a Network Drive), that may be significant and help determine where the issue is coming from.
Debugging: If none of the above are true and you want to try debugging the problem then you can enable debugging in the following way:
- Go to Preferences - Miscellaneous - Advanced
- Set notify_debug to True.
- Set shellchange_debug to True.
- Download the small DebugView tool from Microsoft and run it. (If you see an error message about extracting Dbgv.sys you can ignore it as we are not interested in debugging device drivers.)
Note that other programs may also send messages to DebugView and it is possible that some of the output you see will not be from Opus.
You don’t need to understand the DebugView output, just post it to the forum along with details of the folder/path you are viewing and which changes you were making to the files below it when the output was generated.
When you are done debugging, quit DebugView and turn off the notify_debug and shellchange_debug settings in Opus.
Presumably the problem will manifest in one of two ways: Either no change is detected at all or a change is detected but for a path that is different to the path Opus thinks it is viewing.
If you don’t see any changes at all, create and delete a couple of files on C:\ to make sure the debug output is appearing. Even when notification is working fine it might take a few events to trigger the debug window to appear. The best bet, once you’re in a situation where notification isn’t working, is to switch on the debugging mode, then create/delete some files on C:\ to make sure the debug window is visible, and only then start to make some changes in the folder that’s having problems to see if any debug information is displayed for it.
If needed, post the output you see in DebugView to the forum for advice. You can use File > Save As from DebugView to save the log to a text file, or take a screenshot (be sure to make the columns wide enough to see all the information).
A tool that may come in handy when diagnosing these problems is Microsoft’s Process Monitor (not to be confused with Process Explorer by the same people).
If Opus doesn’t detect any changes, check which changes Process Monitor is able to see. The details it shows may help diagnose the problem. Within Process Monitor, you can save a .PML log file, to zip and submit as part of bug reports, using File > Save.