Windows - No Disk exception


#1

If I try to do file.existsAsFile() on a USB card reader (which has no card in it), I get the infamous “Windows - No Disk” exception (triggered by GetFileAttributes call).

Anyone got an idea how to make sure there is media in a USB card reader drive? I noticed that serial no is zero and volume label is empty, might perhaps be a way? Anyone have opinions on that approach?

TIA
/R


#2

I have a very similar problem with misconfigured PCs that believe that they have an A drive when one is not physically present.

This unfortunately is not a get the user to fix it situation since an huge number of PCs (all the Dells in our lab for example) come that way, and on many it can’t be fixed.

The problem is, I have no way of knowing when I iterate over drives, and polling the drive to find out if it exists at all generates an exception.

Right now I’m just skipping the a drive altogether, but that’s busted.


#3

Any idea what I could do to replicate this?


#4

Simple, insert a USB card reader and do not put anything in it. That will give you a couple of drives but with no content. Then do a file.exists() with a path that resides on a non-existing media. Bam!

Oh, btw, I worked around it by checking the volume serial number, which is zero when there’s no media (and doesn’t pop up that annoying dialog)


#5

Ok, I’ve replicated it with my (empty) CD-rom drive. No idea what to do about it though! Can’t find any better alternative functions for finding out whether a file exists, and don’t want to slow down the exists() method by calling GetVolumeInformation every time. Hmm.


#6

Yes I know, its a real nuisance. You’d think that GetFileAttributes would suffice…

How about just checking GetVolumeInformation if the drive is an USB drive? Then again that would exlude floppies… but then again, again… who’s using floppies these days? :slight_smile:


#7

Well you don’t know what kind of drive it is until you’ve called that… and I don’t want to have to call it inside every single fileExists() call, because it’s so rarely needed.


#8

I see… well I’m out of ideas, the only thing I’ve tested that works is the GetVolumeInformation call failure… :frowning:

Maybe some Windows guru can come up with something else…


#9

What about using _stat ?

http://msdn2.microsoft.com/en-us/library/14h5k7ff(VS.80).aspx

checking errno if _stat returns -1.


#10

Unfortunately _stat propagates ultimately to a Win32 API call, so the problem remains…


#11

Well you don’t know what kind of drive it is until you’ve called that… and I don’t want to have to call it inside every single fileExists() call, because it’s so rarely needed.[/quote]

Couldn’t you use static state flags for the drive, so that the heavy check is only performed the first time the drive is accessed, and then follow up media present tests are only needed if the drive is removable.


#12

[quote=“valley”] The problem is, I have no way of knowing when I iterate over drives, and polling the drive to find out if it exists at all generates an exception.

Right now I’m just skipping the a drive altogether, but that’s busted.[/quote]

If you want to get at least rid of Windows’ message box displaying that there’s no disk in the drive you can use: SetErrorMode(SEM_FAILCRITICALERRORS); and it won’t show up anymore.


#13

Thanks zamrate, that’s the neatest solution.


#14

Ah - great suggestion! But could there be any unwanted side-effects of disabling these error boxes?..


#15

Yeah, had that thought too… otoh the Win32 API calls still return error codes so as long as the application handles them, I guess you’re fine…

But don’t put this disabled mode as default in JUCE, rather make a note in File::exists() (or somewhere else relevant) what you can do to remove the dialogs.


#16

Looks good to me so far.

Cheers zamrate!