It seems that when I have this setting: Prefs > Launching Opus > Explorer Replacement > Don't Replace Explorer
Then listers do not refresh automatically.
When I change to Prefs > Launching Opus > Explorer Replacement > Replace Replace Explorer for all file system folders (Recommended)
Then listers start refreshing automatically.
Is this normal?
Can listers be made to refresh automatically with Don't Replace Explorer set?
Ok here are some results. Background Unknown Date - Been running Opus on my home laptop for X years. Not sure when last updated. Oldish version 12.x as I am usually like to stick with what I have got if it is stable. No issues. Jan 2022 - Installed Opus 12.26 on work laptop. Had issues immediately still happening now. I assumed at the time this was laptop specific and I live with it Aug 2022 - Home laptop upgraded from unknown 12.x to current 12.29. Issues immediately. Intermittent in nature.
Action Taken Action - Create new file with 3rd party software
Target Folder = D:\OneDrive\T01\SS\SS 2022 New Filename = 2022-09-12 12h55m01.png
DebugView++ Output Att01 T=9.98s New Filename Creation Time = This is at lines 6-8 in output. T=18.05 = Don't know what this is. No change on the screen at this point. Lines 9-20. T= XXX = After Line 20 I highlight the Opus lister and hit F5. This refreshes the screen and the new file becomes visible. There is NO correcponding Debug output at the time.
T=XXX+ = At this point I select the newly visible file. The screenshot displays in the lister. No corresponding debug lines appear at the time T=30s = More stuff appears in DebugView. References made to the screenshot folder that was in play above.
I took a screen video of the above test with a timestamp running in the video.
Might be helpful to see possible timing discrepancies between the video i.e. what is actually seen on the screen and what the DebugView shows up.
There are only shell change notifications appearing there, which are a secondary type only used to update icons and a few other things. Detecting new files and most other events relies on a more general type of change events.
Those more general events aren't appearing at all in the log, which suggests a problem somewhere in the system.
We've seen anti-virus/anti-ransomware software do this in some circumstances, especially with OneDrive and Documents folders, where they decide they don't trust a process and won't let it see events about what's happening. (There's also at least one antivirus which breaks rename notifications due to a bug, but even with that people still saw a lot of other events.)
Some things to check to work out what's going wrong:
What happens if you show the Desktop folder in Opus, and create a file there with another tool (not the same screenshot tool)?
Does the file appear in Opus? Is the problem restricted to the OneDrive folder/sub-folders, or to files created with the screenshot tool?
If other software is looking at that OneDrive screenshots folder, can it see the files being created by the screenshot tool?
If you run the ChangeTest program linked near the bottom of the guide, does it report any change events, or is it not getting them either?
(Note that ChangeTest.exe only monitors C:\ by default, although you can tell it to monitor other drives. A test on C:\ should be enough to tell if the general notification system is working or not.)
Adding this link as I think it is related.
This matter has been plaguing me so give me some comfort to see I am not the only one (Though I do not wish this on anyone!) OneDrive Synced folders cannot detect content change
I have ended up doing a lot of work to work around this issue as it has started to really hurt and I dont have a handle on it at all.
A few notes about the link above
In the post there is a statement backing off the idea that it is restricted to Onedrive. I have also suspected Onedrive but then saw evidence otherwise. It does seem worse in Onedrive.
I also have this problem but it only happens with synced system folders (documents, desktop...). Other folders in Onedrive are working
I also see this on the desktop an until now I thought this is the same issue but I just realized that I don't sync the desktop to Onedrive.
When the debugs are turned on the fault goes away. I have found the symptoms also to be intermittent.
I tried to debug but as soon as I enable debug it is working!
Quote from @Leo in the other post that is really hurting me. I have a script that assembles multiple commands on selected files and then executed programmatically to rename and move the files. The move command tries to act on the old (pre name change) filename so generating a windows fault. Disaster.
The Windows Desktop often misses changes as well (particularly if a sequence of changes are done to a single file
That one is probably not change notification going wrong. If your script renames a file, and then wants to do further things to it, the script has to use the new name, not the old one, after that point. If you don't have code to change which name/path the script is acting on, it's not going to work. (Doing everything else you want to do before you rename the file is much easier, as it avoids the whole issue.)
Thanks for comments @Leo
Honestly there is a lot I am not sure of accept for my script as described above used to work a treat.
Now it does not.
Am working on consolidating multiple renames and file move into a single command on another post.