External hard drive on NAS wakes up (starts spinning) when Opus Lister opens

Hello. I noticed a problem in Directory Opus 13 BETA.

I have a self-built NAS which basically is a device with external hard drives connected. I only use SMB to access files.

I noticed that when I open the Lister after system reboot (or just a cold start), but the last session had a tab with SMB folder from the NAS opened, then the HDD on that NAS starts spinning as if the folder was read. However, Directory Opus is correctly displaying a message "The network folder has not been loaded automatically because of your Preferences settings." suggesting that it shouldn't be trying to do anything in that location.

It's hard to provide more information besides what I wrote. I think this problem only occurs after the system reboot (or shutdown, then power on). I don't think it's a coincidence, because I notice the spinning start noise at the moment of clicking the Opus icon. I set Opus not to automatically start with Windows.

When you get a chance, could you please check if there were some improvements in Opus 13 that could trigger issue like this?

It's probably something reading the drive's icon, which means checking for a desktop.ini file on the drive. Windows doesn't cache this information like it should, so any time the drive is displayed somewhere (e.g. This PC), it may be woken up to read the icon.

Even without Opus running, I've found it impossible to have drives stay asleep in Windows for as long as I can remember, to the point I turn off the spin-down entirely. Something always wakes them up, and turning them on and off all the time is probably worse than leaving them on, on top of adding a delay if they are temporarily asleep and you then access them.

You could try using ProcMon to see exactly what's being accessed that wakes up the drive.

After a quick check with Process Monitor, after restart it didn't find any operation containing "File" to my NAS address or share name. Strange. I might need to repeat the tests after "cold start" tomorrow, if I don't forget.

When it comes to drive sleeping, I usually don't have problems with that. These drives are nicely sleeping for days (if not weeks) when not accessed. Spinning all my 4 drives would be a waste of electricity :slight_smile: and I wouldn't be able to fall asleep with that noise :slight_smile:

So the only drive that woke up, was the one that I browsed in Opus before shutting down the PC. Could be Windows doing something, but I don't remember it happening when I used normal explorer, or Opus 12 (for a short time before BETA). But then I also saved some custom sorting to folders on that NAS, etc.

Anyway, it's not a big problem, I just need to learn to close that tab when I don't use it anymore. I'll keep eye on it, and try to use Process Monitor more frequently, so we can see what's going on.

Thanks for your replies. I actually used ProcMon just few weeks ago, and totally forgot about this possibility today.

I have a quick update on this issue.

I'm pretty sure now, that there is a bug in Opus 13. When I opened Opus after PC cold start, and the last used tab was a share on the NAS, Directory Opus started loading this folder (with a message that it takes longer than usual), just to display message "This network folder has not been loaded automatically..." when the NAS drive finished spinning up.

So in short: sometimes after reboot Opus loads the folder after the cold start, but doesn't display the content of it.

It's possible that this happens when I turn off the PC without closing the Opus window(s). I remember I had to quickly shutdown the laptop, and I wasn't closing any windows.

Are you sure it's loading the folder listing, not the icon for the folder or some other detail (which could also wake the drive, but usually takes much less time and is not what the auto-loading stuff is primarily there to prevent)?

What did the Process Monitor logs reveal?

What is Preferences / Miscellaneous / Advanced: [Cosmetic] custom_network_folder_icons set to?

Are any scripts installed? They can respond to new tabs and may access the drive as well. (Or, similarly, toolbar/menu items that list the content of the current drive/folder, or drive icons, or anything like that.)

Unfortunately I'm forgetting to start the Process Monitor every time.

The custom_network_folder_icons is set to false.

I don't think I have any extra scrips installed. I added some buttons for quick saving the folder layout, but that's all, and I don't think it would automatically trigger.

I generally reproduced it just now. I could see some "loading" window from Opus, but I can't remember exactly how it looks like. Possibly it's the progress bar with "Reading folder...", but I think I seen something with text that it "takes longer than usual" (but possibly I remember wrong).

Here's how it is:

  • I open Opus by clicking on the taskbar icon (it's cold start).
  • I can hear that my NAS drive starts spinning, the Opus window seems "empty", with visible tab names from the previous session. Then some pop-up window about loading shows up.
  • Right after that (when disk starts fully spinning), the folder displays: "This network folder has not been loaded automatically...".
    So it's loading something just to show a message that the folder was not auto-loaded. Quite strange. I'm pretty sure there was a "loading" pop-up window from Opus, that's why I think it's doing some I/O.

I managed to catch it in Process Monitor.

I had a SMB share open, then rebooted the PC while Opus window was open.

Then I started Process Monitor. After opening Directory Opus I saw the "Reading folder..." popup without clicking anything. Right after that I paused Process Monitor, and I found that it was accessing my NAS share at address 192.168.1.135:


(I intentionally hidden the long folder path by making that column narrow).

The "NAME_NOT_FOUND" is displaying for path: C:\Windows\CSC\v2.0.6\namespace\192.168.1.135. These calls have the same ThreadID (column not visible in the screenshot), as the thread for directly reading \192.168.1.135.

I found the stack for that \192.168.1.135 access:

What was the full path on the NAS?

Just a share + folder.

SMB_ExternalHDD1/Name

It would help a lot if we could have a copy of the ProcMon log (PML format).

I'm sorry, I'm keep forgetting to enable ProcMon on startup. Today I only managed to take a screenshot to show what window shows up after PC reboot.

The disk on NAS starts spinning right after opening Opus, and this window is shown:

and then traditional: "This network folder has not been loaded automatically...".

It's worth noting that the tab has no name text set yet and is shown as "Empty Tab".

Unfortunately, I'm not able to reproduce it every time, and I have quite busy days that's why I can't focus more on it.

However, I don't think it's a serious issue if you can't reproduce it on your end. This could still be windows doing something in that folder. Maybe some new Win11 "security" features are scanning folders on some system function call, like reading folder path using function from kernel32.dll (just guessing).

It's likely resolving the path for the location bar, not reading the directory. But I can only guess without the procmon data.

This makes sense. If it's checking if the location exists, it sends a signal to the NAS to list the folder.

In my opinion, it should skip checking if folders with delayed load exist, and pretend that they exist until user clicks "load". This way it would not send any commands to remote disks on Dopus statup.

The NAS probably caches folders, that's why sometimes it loads without waking external drives up, and after longer delay (e.g. when I start the laptop after few hours) it spins them up again.

I sent a .PML file on private message to Leo. Hopefully that will be enough. Thanks.

This still occurs in Opus 13.3.x (newest BETA version).

It's very easy to reproduce, as after longer inactivity, the NAS just starts spinning up even when the folder content is not loading.

This seems to be a function that checks if the path is still valid. Maybe as a workaround, it should avoid that for network locations?

If you close the Folder Tree (and save that as the default) does it still exhibit the problem?

I'll try to make sure, but I can only reproduce this issue when I leave NAS (smb) tab open before I shut down PC, or just not use Opus for a longer while. It never happens when no smb tab is left. Especially because I don't have mapped drives to the NAS, just accessing it by its network location \192.168.1.x.

To me it looks like Opus is checking if the path is still valid (exists), and this causes Samba to scan the folder for files (?). So for network locations it maybe should skip checking and pretend that they exist until it is loaded manually by user.

I tried this yesterday, monitoring with Process Monitor, and couldn't see Opus make any queries to the network unless the tree was open and I had a folder from that network drive in favorites.

If it's not caused by the tree for you it may be some other configuration setting triggering it, but working out what is the challenge.

I couldn't reproduce it when the NAS SMB tab wasn't open.

I think it's some windows function, such as "DoesDirectoryExist()" called by Opus causing it.

So when opening Opus for the first time after reboot (or when Opus just wasn't running in the background), it checks all open tabs if their path is still valid. For network directories it causes spinning up, as Samba on linux is following the "DoesDirectoryExist()" request.

I couldn't always reproduce it, because most likely Samba was caching this directory and returning status without spinning up the disk. But after few hours of inactivity it again needs to spin it up.

So if there's some function that checks if path is valid in Opus, then it could be worth to add a switch to disable it for network drives. This way, even if path became invalid, Opus would assume it's valid, until user loaded the folder with the delayed load hyperlink.

I'm just guessing, but that's the most probable scenario.

Yes it is almost certainly some Windows function called by Opus causing it. Opus calls a lot of Windows functions :slight_smile:

Working out what makes it happen is the problem, since it doesn't seem to happen here when I try it (except, as I said, with the tree turned on).