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 0.0.0.0 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.
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 2.3.0.2
At copy time, there are two possibilities:
2.3.0.2 does not already exist
2.3.0.2 already exists.
In the second case (where it already exists) the program
.. creates a folder 2.3.0.2.tmp
.. copies the files to the 'tmp' folder
.. renames the 2.3.0.2 folder to 2.3.0.2.save
.. deletes 2.3.0.2
.. renames the 2.3.0.2.tmp file to 2.3.0.2.
.. deletes 2.3.0.2.save
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.
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.
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).
Results:
Windows Explorer - worked fine !
Opus - FAILED !
I've reproduced the problem now, using a couple of batch files:
Starting with 2.3.0.2 already existing, rename.bat creates 2.3.0.2.tmp, 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:
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).
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:
Double-click it
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 2.3.0.2 problem, Opus got the wrong folder (2.3.0.2.save was displayed).
This is my F5 definition:
By the way, unrelated to the 2.3.0.2 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.)
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.
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.