Folder treenot being refreshed properly

I have a program that dynamically adds folders.

I have a folder tree and a folders contents pane.

The initial Opus view:

I then run the program. It creates 2 folders under 'Versions' folder:

The folder contents folder updates very soon thereafter:

Note that the folder tree did not update (even when I collapse and uncollapse the folders.

In the folder contents pane I clicked on the folder to show contents and tehn went back out. The folder tree remained unchanged (missing the new folder).

I then clicked on the new folders in the folder contents pane. Each time I licked on a new folder it showed up in the folder tree as well.

I had to click on both to get the two new folders to appear in the folder tree:

To me it looks like the folder tree is not updated properly. At the very least it should get updated when I collapse and uncollapse the Versions folder.

Have you checked everything in Changes to folders are not being detected ?

I checked the link.. my system has none of the conditions identified there.

The problem is Opus-specific. The Windows Explorer shows the folders correctly.

Furthermore, in Opus, even after I refreshed (F5) the problem persists.

Worse yet, the tree pane and the folder view don't agree on the names.

Here's Windows explorer:

Here's Opus (I had two instances to make sure the issue is real):

Separately, I opened a 3rd instance after the problem showed up:


Notice that this is correct (matches Windows Explorer).

Here's the scenario:

I developed a program that copies files into the folder

At copy time, there are two possibilities: does not already exist already exists.

In the second case (where it already exists) the program
.. creates a folder
.. copies the files to the 'tmp' folder
.. renames the folder to
.. deletes
.. renames the file to
.. deletes

The reason for this elaborate process is to be failsafe in case something goes wrong with any of the uploading/copying.

Looks like running instances of Opus get confused. by this deleting and renaming.

The 3rd instance that I opened after the activity shows things correctly.

The other 2 instances show the error even after repeated F5 attempts.

The FAQ I linked to talks about diagnostic/debug output. What does it show for that sequence of events?

Do you have Kaspersky installed?

No Kapersky.. just MS Defender

Folder: C:\Talenya\Code\TseShard\Production\Versions

DebugView++ log: (included zip file): (20.9 KB)

Thanks for the log.

It shows this sequence of events, at least as reported by the OS:

8.682113	2021/02/09 10:57:25.592	90144	dopus.exe	[90144] [9156] dopus: Change ren_old  on C:\Talenya\Code\TseShard\Production\Versions\
8.682175	2021/02/09 10:57:25.592	90144	dopus.exe	[90144] [9156] dopus: Change ren_new  on C:\Talenya\Code\TseShard\Production\Versions\
8.682245	2021/02/09 10:57:25.592	90144	dopus.exe	[90144] [9156] dopus: Change modified on C:\Talenya\Code\TseShard\Production\Versions
8.682310	2021/02/09 10:57:25.592	90144	dopus.exe	[90144] [9156] dopus: Change ren_old  on C:\Talenya\Code\TseShard\Production\Versions\
8.682374	2021/02/09 10:57:25.592	90144	dopus.exe	[90144] [9156] dopus: Change ren_new  on C:\Talenya\Code\TseShard\Production\Versions\2.3.0.


  • (old folder) ->
  • (new folder) -> 2.3.0.

Note the missing 2 on the end of the final name.

Does the real folder have the 2 on the end, or is the name really 2.3.0 or 2.3.0. in the filesystem as well?

A name with . on the end will confuse a lot of Windows APIs, which may be a factor, if the tool doing the renaming is specifying the wrong name by mistake.

It's also possible the change notification system is reporting the wrong name for some reason.

The names are:

[as can be seen in the screen shots]

My guess is the DebugView


To get to the bottom of this issue (I really think this is an Opus bug), I ran the scenario with the Windows Explorer and Opus running. I also ran dbgview64.exe (not the ++ version).

Windows Explorer - worked fine !
Opus - FAILED !

Here are the screen shots:

Windows Explorer

Opus before hitting F5:


As you can see the folder shows up in the folder tree but not in the folder view.

I then hit F5:


As you can see, the tree shows --- which is WRONG!

Finally, here is the captured log:(I renamed it to .txt suffix so that I can drag it to this message):

DJM-DEKSTOP.txt (195.3 KB)

I've reproduced the problem now, using a couple of batch files:

Starting with already existing, rename.bat creates, copies some files into it (this step, or at least the delay, seems to be important), then does the rename. This will trigger the folder tree to not show the new folder until refreshed:

copy C:\Windows\*.exe

The second batch file, restore.bat, just undoes that, so you're ready for another test:

rmdir /q /s
move (1.9 KB)

Now that we can reproduce the problem we should be able to fix it. We have some special code to track this kind of change for files but maybe this particular sequence is confusing it, or it doesn't work on folders currently. Need to look in more detail.

For me, pushing F5 is enough to make the tree see the new folder. My F5 key runs Go REFRESH=source, which should be the default (unless your config dates back to quite an old version, at least).

I'm glad you can reproduce it (I'm a software developer who has learned to appreciate it when bugs are reproducible - makes them easy to fix).

My first Opus goes way back.. so far back that I don't even remember the first release I purchased).

How do I edit what my F keys do? (I checked Settings but didn't find it there)

-Thanks for working on this problem

Right-click an empty area of a toolbar and choose Customize or go to Settings -> Customize Toolbars.

Switch to the Keys tab.

From there you can either just scroll down to find F5 or turn on the little "Z" button to the right of the Filter field at the bottom. (It will have a blue background if on and no background if off.) Click in the Filter field and press your F5 key to capture that.

Two ways to edit it:

  1. Double-click it
  2. Select it, then either click the Edit button (pencil on paper icon) or press Alt-E.


My F5 is configured the same as yours, yet when I refreshed the problem, Opus got the wrong folder ( was displayed).

This is my F5 definition:


By the way, unrelated to the issue, when I followed your instructions to get to the F5 definition, the dialog box appeared in a non-expected screen location.

I have 3 monitors (I develop software).

The Opus instance was on my middle monitor but the 'Customize' dialog popped up on my 1st monitor.

It took me a while till I noticed where it showed up (my monitors are all 30-inch size).

My expectation is that the dialog should pop up in the center of the parent rather than(apparently) remembering its last location.

Remembering last position when there are multiple instances of Opus running on multiple monitors makes very little sense (to me).

I believe it should always pop up in the center of the parent window/control.

Customize remembers the monitor it was on last, since you might want it out of the way of what you're editing. If it's not where you want it, just move it, and it will be there the next time.

There's only ever one instance of Opus. Multiple windows all come from the same process and are all edited at once if you go into Customize mode.

(This is a little off-topic for the thread so please start a new thread if you want to discuss it more, but the way it works is by design.)

We've tracked down the problem and written a fix which will be in the next beta (12.23.2).

Thanks for reporting it, and helping us track it down!

I'm very glad to help... As a software developer I depend on Opus throughout my work day (and, frankly, any time I'm using my computer). It really is indispensable.

1 Like

Today's new beta contains the fix: Directory Opus 12.23.2 (Beta)

still getting this fault on very rare occassions with usb devices have to shut down and restart directoy opus sometimes.

Do you mean the tree is out of sync more generally, or that specific sequences of renames cause a problem, which is what the thread is about?

What are the sequences of renames which cause the issue, so we can try to reproduce them?

Or, if it's a general issue, please start a new thread with full details of what you're seeing and what you've tried. Check if F5 refresh, or closing and re-opening the tree, or opening a new lister window reveals the folders or if they are still not visible, and let us know the details.