Heavy delay navigating folders, file displays, clicking path bar

Hi there! o)

As mentioned in another post, I struggle with DO for some months now and now I took the time to investigate the issue a little deeper. The problem is, that there is a heavy delay whenever I switch folders, toggle src/dst in a dual display or just click the path bar. The delay is around 1-3 seconds, sometimes even more, surely depends on general system load.

What I did so far:

  • uninstall DO (I never did that in my whole life before.. o)
  • installed latest version including reboot
  • used fresh config for some days, no issues!
  • restored my config, delay issues back again
  • disabled basically all non-microsoft shell extensions with ShellExView
  • disabled most of file associations with ShellExMenu I don't need, never used
  • disabled all scripting via DO
  • disabled all scripting by renaming "Script Addins" folder to "Script Addins_"
  • deleted all labels
  • restarted between all these steps
  • closed all open tabs but 2 (leaving 1 with a random path in src/dst)
  • narrowed down lister to just a single filedisplay (no more dual, no more viewerpane)
  • closed all toolbars
  • looked into debug view for any output (none there related to DO)
  • looked for any "advanced" debug settings which might be enabled

No result, the delay is still there.
The only thing I was able to find was a massive output/activity during the delay with the help of "Process Monitor". DO will flood the log with 148k events when switching folders or just activating the path bar via click (in a dual). Around 13k events come from "dopus.exe" and they look like shown below. It seems DO "touches" a trillion of folders and paths which I surely used, but maybe month/years ago. Not sure, not a single one of the paths listed in the "Process Monitor" log is open in any DO tab right now.

If you have any clue, please help! o)
Thank you! o)

I also..

  • cleared favorites, disabled smart favorites
  • checked with "explorer.exe", no problems
  • cleared file collections
  • some more things I cannot remember.. o)

Must be config related, but it sounds like you've tried most things.

Would you be able to send us the Process Monitor .PML log of what happens? (They're usually huge but compress well.)

The config backup might also be useful so we can try it ourselves, if there's nothing sensitive in it.

To keep them both private, please email them (or gdrive/onedrive/dropbox etc. links) to crashdumps@gpsoft.com.au

Thank you Leo, I'm quite sure there is sensitive information in my config, so I'd like to try some more without.
Especially after digging through all the internal/config files of DO, I realized how much history there is! o)

Anyway, I'm one step further.
It seems when I disabled all the toolbars, I forgot the one I usually have between the dual file displays. There are a lot of path related buttons on there and I seem to have found the root for all the weird paths showing up in ProcessMonitor. They seem to be from a filecollection ../Collections//FlatView-Cache/FlatView-Selected.col. The weird thing is, removing this collection file does not help in any way. As soon as I bring my path toolbar up and start navigating folders as usual, ProcessMonitor starts to dump the massive amount of entries where DO seems to look into all the paths from the file collection file.

Does that ring a bell for you?
Is there another other place I could look for flatview/collection related, cached data?
I totally removed the Collections folder and restarted DO, no change, the paths contained in the mentioned collection keep dumping in ProcessMonitor. If i close my path-toolbar again, the issue is gone.

We are getting somewhere! o)

I tracked down the button on my path-toolbar which is causing this. The button is only visible in customize mode (hu#1?) and shows up as "New Button". If the button is removed, the issue seems gone. If I add it, the delay is there again and ProcessMonitor starts dumping the paths from the file collection mentioned (although the collection has been removed from filesystem (hu#2?).
The button seems to be some leftover, not sure why it won't show up in non-customize mode. It doesn't look too harmful to me, but this thing seems to have major impact on the issue.

<?xml version="1.0"?>
<button backcol="none" display="label" textcol="none">
	<label>New Button</label>
	<icon1>#newcommand</icon1>
	<function type="normal">
		<instruction>Go D:\tmp FOLDERCONTENT=nofiles,button,nomenusel</instruction>
	</function>
</button>

Does D:\tmp exist? What kind of drive is D:\? Is the tmp folder a junction pointing to something else? Or is anything in the tmp folder?

Yes, D:\tmp exists and there are a lot of files and folders in there.
Around 8GB, 50 folders with various stuff in it. I found one junction to my dropbox in there, that should not be there, removed that.

Interestingly, I noticed a lot of paths and foldernames in D:\tmp, which previously showed up in ProcessMonitor and which were also in the FlatView-Cache collection. The collection seemed to be made from files from D:\tmp, which probably made me think, that there is a correlation to the collection file. But since I removed that and we found the D:\tmp button, pointing to a folder with quite similar content, this might just resolve the collection issue.

So basically, it seems DO went nuts on D:\tmp because of this button, which kinda makes sense, in some way, but not really, since I never pressed the button?! o)

go foldercontent will enumerate everything in that folder and generate buttons for the things below it. You don't need to click anything for that to cause problems if the folder has things that cause a delay when Opus asks the OS for information about them.

Yes, I also saw the folders being accessed occasionally while not touching DO, but definitely after each folder switch or src/dst-toggle or click into path bar. Is that intended? It's quite understandable that this causes DO to hang like it did for me, if there is a huge structure involved.

Yep, that's how it works. Toolbars get updated on folder change (and lots of other things).

You can put it into a submenu to avoid the overhead until you open the menu.

Ok, so everything works as designed and lots of uninvolved stuff checked for no reason. o)
I still wonder why the button never showed up, but I can live without knowing why. More important is, that I can use my DO setup again as it is intended.

And believe me, this is a relief! It kinda makes me happy. o)

Using the default config was an emergency solution for 2 weeks now, since I could not bear the situation any longer. I suffered for months and rejected things I should have done long ago. But with the default setup you notice every second: Missing hotkey here, missing button and folder format there, a pain if you're used to your own multi function cockpit. Thank you! o)

You've put a command on a toolbar saying "please show the content of this folder" and you think it's looking at that folder for no reason?

No, I don't think it looked there for no reason, where did I say that?

The problems I had were due to the button being visible in customize-mode only (for yet unknown reasons) and for heavily delaying basic activity within a lister continuously and repeatedly.

I don't know why a go menu button would read the specified folder again and again whenever I toggle src/dst or click into a path bar of file displays totally unrelated to where the button is pointed to.
You say that's how it works, I will go and remove all these buttons now, since they seem to trigger folder reads on locations repeatedly (and unnecessarily?), where I probably don't want them to happen that often (network locations/sleeping harddrives e.g.).

I expected these GO menu buttons to be read whenever the toolbar is opened they reside on, whenever there is a folder change event for that folder location and maybe at some other time, but surely not with seemingly unrelated actions in the DO interface.

I hope you can see where I'm coming from now, I never questioned looking into the folder where a menu is to be build of, of course not.