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 188.8.131.52
At copy time, there are two possibilities:
184.108.40.206 does not already exist
220.127.116.11 already exists.
In the second case (where it already exists) the program
.. creates a folder 18.104.22.168.tmp
.. copies the files to the 'tmp' folder
.. renames the 22.214.171.124 folder to 126.96.36.199.save
.. deletes 188.8.131.52
.. renames the 184.108.40.206.tmp file to 220.127.116.11.
.. deletes 18.104.22.168.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.
I've reproduced the problem now, using a couple of batch files:
Starting with 22.214.171.124 already existing, rename.bat creates 126.96.36.199.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:
Select it, then either click the Edit button (pencil on paper icon) or press Alt-E.
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.