Interminable wait "Reading Folder" on SharePoint/OneDrive folder

I am approaching the end of my 60-day trial. Overall, there is much to like, but I've also run into quite a few things that could be improved and this one "fatal" flaw.

This is, for me, the worst thing. I decided to try D.Opus because I wanted something more reliable and with better performance than Windows Explorer. In general, it seems to deliver. However, when I open a folder that is sync'ed with OneDrive (including SharePoint, where I spend a lot of my time), it quite frequently takes a long time to read the folder and display it. I get this, which is reminiscent of the spinning hourglass:

image

Sometimes it takes 5 seconds, often it takes 20-30 seconds or more. I've even had a case where it took over 10 minutes! I've also had cases where I simply ran out of patience, copied the path, opened Explorer, pasted it, did whatever I needed to do, closed Explorer -- and D.Opus was still chugging along reading the list of files...

I hope there is a simple setting I can change that will fix this issue. If not, I hope you can promise a release soon that addresses this issue.

I like D.Opus a lot, but this one issue can be a deal breaker. Having to return to Explorer much of the time gets old real fast.

There is most likely a shortcut in there that points to something which takes a long time to resolve, combine with turning on the option to sort shortcuts to folders like folders. Shortcuts that point to unreachable network servers are often the cause of that.

It's also possible something has installed a shell extension which is going wrong.

The best thing to do first is to narrow down which file (or type of file) is causing the delay.

You can also send us process snapshots taken while the delay is happening, which we can analyse to see where the wait is, and whether it's in Opus itself or another component, and then fix it or suggest workarounds as appropriate.

More detail in the FAQs:

Thanks. First off, it does not appear to be a CPU overload issue. Here's a snapshot of CPU activity while it was busy "Reading folder..."

FYI, that snapshot is during the first minute. It's now several minutes later & the folder contents have still not appeared. When they appear, I'll past them below.

Other consideration:

  • When I enter a folder & wait & the contents finally appear - if I go down a level & back up, sometimes the display is instant (I'm assuming the results were encached) and sometimes I am back to waiting interminably. NOt clear to me yet when it gets encached or for how long or when it decides to invalidate the cache & it needs to read it over.

  • if there is a problem with "a shortcut in there that points to something which takes a long time to resolve" I would expect Explorer to have the same problem. In fact, I've run into that problem in the past with Explorer. But it doesn't. For example - it's now been several more minute that I'm waiting for a folder contents to appear (see above). I just opened an Explorer window for the same folder and the contents displayed instantly. Perhaps by coincidence the Opus window also showed them just now (finally). In fact, right now as I traipse around in that tree, all folders are displaying in Opus instantaneously.

  • regarding "a shell extension" - I certainly have plenty of those. They don't seem to interfere with Explorer. How might I check if one is not playing nice with Opus?

  • what did you mean by "process snapshots taken while the delay is happening, which we can analyse to see where the wait is, and whether it's in Opus itself or another component, and then fix it or suggest workarounds as appropriate." I assume you mean something more than what I pasted above. Please let me know which tool you'd like me to use to capture the snapshot - or point to an article explaining it. At any rate, right now Opus is snappy on those folders (see above), so I'll have to wait until it happens again.

  • as promised above, here are the contents of the folder that just took close to ten minutes to finish reading & display. I've anonymized the information, but I hope what is left will give you an idea of what I am dealing with. Let me know fi you see anything suspicious. As I mentioned this is a SharePoint folder tree sync'ed via OneDrive

Thanks again for your quick & pertinent replies - I appreciate it! I'll be happy to work with you to debug it and find what is causing this intolerable behavior.

OK, it happened again. I took 5 dumps as requested here and then a couple minutes later, another two. I sent email to the crashdumps address with the link to the 7z file.

Looking forward to the result of your analysis.

Thanks,
Yosh

The snapshots indicate OneDrive is taking a very long time when queried for sync status.

If you turn off Preferences / Folders / Folder Behavior / Display extended sync attributes for cloud folders, it should speed things up, but you will see less detailed sync status within Opus:

With this option off only online/offline state will be reported; with it turned on, other states like "synchronizing" can be shown.

That was needed for older versions of Windows 10 but should not be needed for current versions, unless Microsoft have broken something yet again. (Which is fairly common for the OneDrive team, to be honest.)

Thanks. I wanted to try that, as you suggested. However, when I went to my preferences, the option was already turned off...

Any other ideas I can try?

BTW, if the dumps indicate it WAS waiting for sync status - then maybe you have a bug that it isn't respecting the off-state of the option?

Does it help if you turn the option on? (I think the checkbox may be reversed, from a quick second look, but it's not code I'm familiar with so I may be wrong.)

Yes!

Instant display now!

I'll continue to monitor and let you know if it starts lagging again.

thanks!

(I suppose you'll need to change the wording on that option to match what, apparently, the code is doing.)

Just wondering - are you going to fix that? Probably the best/easiest way is to negate the label of the option so the sense of the checkbox matches reality, e.g., instead of "Display extended sync attributes for cloud folders", use "Don't display extended sync attributes for cloud folders".

The checkbox was fixed back in November: Directory Opus 12.25.4 (Beta)

OK - I see it says in the release notes:

The Display extended sync attributes for cloud folders option was backwards. Note this has been reset to off for everyone.

Thanks! I just need to have more faith :slight_smile: (and to read the release notes all the way through)