Delay opening lister when hard drive is asleep

I've got three SSDs and one HDD in my desktop. The HDD is only used for storage and less-frequently required files, so I've told it to go to sleep after a while. When it's asleep, opening a new lister causes the drive to wake up, but the lister won't appear until after the drive is back up to speed (I can hear it spinning up, so I'm confident that it's the reason the lister is delayed).

My default lister opens to the root of one of the SSDs, but one of the default toolbars contains a button for direct access to the HDD. The button has a couple of manually created links to specific directories and one using the Opus "recent" command. I'm guessing that one or all of these require the HDD to be awake before the button is ready, and that the lister won't appear until the button is ready. (I do have some other buttons that might also require the drive to wake up, I guess, like the "My Computer" button with the command "Go /mycomputer", but my assumption is that since they're not dynamic, they don't care that the drive's asleep.)

So other than taking that button off of the toolbar (which I'm going to test later) or stopping the drive from sleeping, is there anything I can do to lessen the delay before the lister opens? Code of that button is below, in case it's relevant.

Thanks.

<?xml version="1.0"?> <button display="icon" label_pos="left" min_width="yes" popout="bottom" separate="yes" type="three_button"> <label>F</label> <icon1>#NJM_MiscIcon:HDD-F</icon1> <button display="icon" label_pos="left"> <label>F</label> <icon1>#NJM_MiscIcon:HDD-F</icon1> <function type="normal"> <instruction>go F:\</instruction> </function> </button> <button display="icon" popout="bottom" type="menu"> <label>F</label> <tip>Go to fixed/recent directories</tip> <icon1>46</icon1> <button display="both"> <label>F:</label> <icon1>#NJM_MiscIcon:HDD-F</icon1> <function type="normal"> <instruction>go F:\</instruction> </function> </button> <button display="both"> <label>Archives</label> <icon1>109</icon1> <function type="normal"> <instruction>go f:\archives</instruction> </function> </button> <button display="both" separate="yes"> <label>WoW Archive</label> <icon1>F:\World of Warcraft\Wow.exe,0</icon1> <function type="normal"> <instruction>Go &quot;F:\Archives\Games\WoW&quot;</instruction> </function> </button> <button display="both"> <label>Recent dirs</label> <icon1>49</icon1> <function type="normal"> <instruction>recent F:</instruction> </function> </button> </button> </button>

Update:

Took the button off of the bar and it seemed to prevent the wake-up call, as I'd guessed. Put the button back minus the"recent" list and the lister still wakes the drive. New guess: it's the drive info in the tooltip for the button that's doing it?

If you ask me, it looks like it's waking the drive up because a buttons icon is coming from an .exe located on that drive. Use an icon that's located under /dopusdata instead. Even copying Wow.exe to /dopusdata(somewhere) if you still want to get the icon from the .exe.

That would definitely be a candidate. (It's possible more than one thing is doing it.)

Windows is pretty bad at caching icons on sleeping drives and tends to wake them up just to get an icon you would think it already had in memory.

The button's icon is from a .dis file I've knocked together, so it's going to be in my user directory on an SSD. However, one of the fixed locations does indeed have an icon on that drive. I'll fix that and see what it does. Saying that, the two fixed locations are, of course, on that drive too. Does Opus have to check that they still exist before it displays the button? I'd have thought not: don't see why it'd care until/unless you actually tried to navigate to the location.

The best way to diagnose the problem would be to use Process Monitor to log what accesses occur to the drive in question.

This icon from the above XML is not in a .dis file:

<icon1>F:\World of Warcraft\Wow.exe,0</icon1>

[quote="leo"]This icon from the above XML is not in a .dis file:

<icon1>F:\World of Warcraft\Wow.exe,0</icon1>

Yeah, that's the other one I mentioned. I've changed it to point at one on an SSD, but I'm not yet sure how much difference it's made.

I've been looking with ProcExp, as suggested, but I'm not entirely sure what I'm looking for (other than Opus accessing resources on the F: drive) and it's a bit hit-and-miss as to whether the drive's asleep or not when I open a lister. However, I've just opened one which came up immediately: I assumed that the drive was awake, but I heard it spin up when I clicked on the drive button. I'm not sure whether it would have awoken for the tooltip (I didn't wait long enough to see because I thought the drive was awake) but I now think that removing the recent directories list from the button (which I did last night) might have been enough to keep the drive asleep. I'll just have to wait for the drive to nod off again before I can test it.