[bug] very unfriendly handling of missing drive

[jdmarch]

All of a sudden FARR has become unusable for searching. As soon as I type a character in the search entry field, up comes a popup "No disk in drive . Please insert a disk into drive D:"

I expect that this is caused by some old shortcut links which migrated from my previous system 6 weeks ago, which still do point to a (now nonexistent) drive D:. But FARR doesn't even tell me which link is causing the problem. I can't tell you exactly when this problem emerged because 1) I'm not sure when I did my most recent FARR updates and 2) recently I've been working on a limited number of tasks so have been able to select the program from FARR's "most recently used" default list, which does not cause this problem to emerge (no typing on the search line).

Help! Thanks.

FARR 2.12.03

[mouser]

good point.

try going to your history and deleting any entries refering to drive d.

maybe i can have farr figure out when something is on a removable disk and not add it to history if so.
anyone know if there is a nice windows api call to check if a drive is removable?

[jdmarch]

Thanks, mouser.

Deleting the entire history list does not help. (Anyway, there were no explicit references to drive D: in the history list, and the problem did not surface when the MRU list appears, only when I start to type on the search line. I really do think it's more likely that the drive D: references are in LNK files somewhere in the search folders.)

Temporary workaround: putting a CD into my CD drive (drive D: on this system).

It seems that this is a new bug. I've certainly used the search line many times since I migrated to this computer, without this problem occurring, but it's just possible that  by serendipity, I've had a CD in the drive every time I've used the search line.
 

[mouser]

I really do think it's more likely that the drive D: references are in LNK files somewhere in the search folders.

hmm that is strange..
or a new shortcut.

try this, set this option and then see where it says it was searching when the error pops up, it's useful for debugging:

[mouser]

if we can confirm its new as of v2.08 or so, then it may be that a recent change i made to short resolution is causing it, and i can revert back.  maybe ill revert back for a test version for you to try.  just do me a favor and dont permanently delete the shortcut causing the problem if you find it, so that we can easily try a new fix if/when i come up with one.

[d4ni]

I had a similar issue, it included a mounted virtual CD-ROM device using daemon tools. I am sorry, I can not exactly remember the details but I can confirm this is an issue sometimes. I resolved by removing all history items pointing to the device if I recall correctly.
The same does not seem to apply to usb thumb drives that are attached and detached though..

[jdmarch]

That's a handy trace option - found them! I've moved all the D: referencing .LNK files into a subfolder and blocked recursion into that folder, solving the problem for now.  I can re-enable it any time you'd like me to test again.

I'll be happy to test v 2.08 if you'd like. If I do so, I'd like to make sure that my current options don't get lost/corrupted; please let me know whether I should back them up, and if so, please remind me where they live... I'm not finding this option anywhere in the configuration dialog.

[f0dder]

Imho if it was caused by a reference to a now-noexisting partition (whose drive letter is now mapped to your CD), this isn't really a FARR bug - but the effects are certainly annoying nonetheless.

Results are much worse with shortcuts to other computers (that have gone offline) - not an issue with FARR right now though, because UNC paths are ignored.

[mouser]

Imho if it was caused by a reference to a now-noexisting partition (whose drive letter is now mapped to your CD), this isn't really a FARR bug - but the effects are certainly annoying nonetheless.

well there are a few ways you can make a request via windows api to ask the OS to resolve a shortcut.. some tell windows to try to resolve and find near matches if the original is missing, etc.  it's not at all certain but it's possible that one of the options tells it to prompt for missing media and one doesn't, so i'll have a look.

[jdmarch]

Imho if it was caused by a reference to a now-noexisting partition (whose drive letter is now mapped to your CD), this isn't really a FARR bug

-f0dder (June 30, 2008, 09:10 PM)

I do not want to quibble, but imo one thing that distinguishes a good program from a mediocre one is the ability to handle external error conditions gracefully. Since FARR is not merely a good, but a a great program, we certainly  don't want any unfriendly error handling!

[phitsc]

anyone know if there is a nice windows api call to check if a drive is removable?

-mouser (June 30, 2008, 02:14 PM)

GetDriveType will tell you if a disk drive is a removable, fixed, CD-ROM, RAM disk, or network drive.

[mouser]

great.  thanks phitsc, i can use that to avoid adding removable links to history.

[macs]

i can use that to avoid adding removable links to history.

-mouser (July 01, 2008, 12:37 AM)

I'm not sure about avoiding adding removable links to the history. I have a USB pen drive in my machine with a range of portable apps that I use very frequently. Then when I'm on the road I just take the pen with me.  From my point of view if FARR never added anything on USB pen drive to the history then the history facility would be much less useful.

Is there way FARR could filter the history list and not use things on a removable drive if the removable drive isn't there? If speed is the issue then maybe FARR could just check the removable drives when it starts, then if the drive isn't there it filters the history for that session.

[f0dder]

Imho if it was caused by a reference to a now-noexisting partition (whose drive letter is now mapped to your CD), this isn't really a FARR bug

-f0dder (June 30, 2008, 09:10 PM)

I do not want to quibble, but imo one thing that distinguishes a good program from a mediocre one is the ability to handle external error conditions gracefully. Since FARR is not merely a good, but a a great program, we certainly  don't want any unfriendly error handling!

-jdmarch (June 30, 2008, 10:39 PM)

Well, if you try querying a location on a network path that's not available, you will face a long time-out period. This is windows standard, and afaik there's not much you can do about it, except not trying to query network paths.

[jdmarch]

if you try querying a location on a network path that's not available, you will face a long time-out period

-f0dder (July 01, 2008, 07:47 AM)

My report/request was actually about an unavailable drive letter. The exception is raised instantly, not after a time-out period; the question is how it should be handled. Also note that we're talking about a once-removed error (an unavailable linked-to path inside of the referenced LNK file) in a file which may not even be requested to be executed.

[jdmarch]

This problem reappeared today, in a slightly different guise. I did something quite unusual, namely put a music CD into my computer's CD drive, which it recognized as the D: drive. I then ripped it and removed it. The next time I used FARR (i.e. very soon ), FARR complained and would not proceed, just as described in my OP.

I found that there was an obsolete shortcut file in a folder on FARR's search path; the shortcut pointed to drive D:. When I deleted it, the problem disappeared. But this seems worth reporting for two reasons:

1. It seems that as long as drive D: did not exist, FARR was perfectly capable of ignoring that shortcut. Apparently FARR recognized when drive D: came into existence, but not when it went out of existence. Could this be improved?

2. It was very helpful (essential!) to use the diagnostic option "show search subdir details on status bar". It would also be helpful to have a sub-option "show search file details on status bar" to speed up the final diagnostics step.

Thanks!
A happy and peaceful new year to all.

[mouser]

This bug should be fixed as of v2.96.01.

[jdmarch]

That's some serious long-term follow-up, mouser. Thanks!