Looking for a reliable way to determine if a drive letter is in use
#11
Thanks to all who responded. I'll go through all the suggestions to see what works, but I did figure out a kind of kludge way of making it work for now.

I found that I could use "SHELL" to run a command like

dir D:\ > DriveStatus.txt 2>&1

This will direct the standard output as well as any error to a text file called DriveStatus.txt

If the drive letter is really and truly not in use this will return a message that says "The system cannot find the path specified".

In either of the other two cases that I noted in my original post, it will return a different message for each of those situations. As a result, I can parse that DriveStatus.txt file to determine exactly what the state of that drive is.

It's just a little ugly, but it seems to be working.
Reply
#12
(05-08-2023, 04:53 PM)mnrvovrfc Wrote: What is the result of "vol F:" on the terminal on Windows?

https://www.abrirllave.com/cmd/comando-vol.php

In Spanish, but it says "ERRORLEVEL" function of CMD.EXE raises one if the drive/label doesn't exist.

There's the visual example of trying to open an E: drive which is "not ready", and an M: drive which the system couldn't find.
Reply
#13
mnrvovrfc,

Using a command such as "vol F:" didn't quite work out for me.

But I have a solution that is working for me now. I started with a little proof of concept test and when that worked I put it in my 16,000+ line QB64PE code where it seems to be working flawlessly now.

What I discovered was that in each of these scenarios where a removable drive like a USB Flash Drive (UFD) still shows up in File Explorer with a drive letter but there are no actual partitions on the device, diskpart will list that volume as being 'Unusable". So, I simply have my code do this:

1) Generate a list of all volumes.
2) For any volume that is both removable type media AND having a status of "Unusable", I select that volume in Diskpart and issue a "remove letter=x" where x is the letter still showing up in File Explorer.

That frees up that drive letter and allows drive letter detection to then no longer stumble over these odd UFDs.

This is a program I've been working on and expanding / refining for several years now and all that time I have had these odd little corner cases with drive letter detection. I finally took about a day and half to do some intensive troubleshooting of the issue and it looks to me like I finally have this resolved.

Thanks to all for the suggestions and ideas.
Reply
#14
Would something as simple as this not work?

Code: (Select All)
For i = 1 To 26
    d$ = Chr$(64 + i) + ":/."
    If _DirExists(d$) Then Print Chr$(64 + i); " found."
Next
Reply
#15
I do believe that hanness said that he tried that first and found it to be not a good enough solution
Schuwatch!
Yes, it's me. Now shut up.
Reply
#16
(05-09-2023, 01:22 PM)Ultraman Wrote: I do believe that hanness said that he tried that first and found it to be not a good enough solution

Steve added the dot (.) for root in his example as I suggested. Was this tried hanness?
Software and cathedrals are much the same — first we build them, then we pray.
QB64 Tutorial
Reply
#17
I had not tried the dot yet. I'll try it when I get back in front of my main PC where I have all my thumb drives.
Reply
#18
I tried the code with the dot. It also fails to identify the fact that these drives have drive letters already assigned to them.

But it's all good. The method I came up with now may not be really elegant, but it works just fine.
Reply
#19
If one connect an external drive or a stick, the system (Windows) always assigns the next free drive letter. With me the L:\ - Just plugged in:

[Image: LW-Buchstaben.jpg]

If I connect something else, it's M:\ and so on.
Reply
#20
Yes, under normal circumstances, it assigns the next available drive letter for me as well. But the point here is that it is assigning a letter to a drive that has no partitions on it and is inaccessible. If you try to access the drive letter that is assigned to that device, it will fail because in actuality, there is nothing there to access.

I think I understand why Microsoft probably does this. My guess is that it is a way to "preserve" the drive letter that this removable device had so that when you do create a partition and format it, it will automatically have the same drive letter that it had before.

But as noted, that causes problems.

Anyway, I'm done dealing with it now. I've been hammering the snot out of my solution and so far it seems bulletproof.
Reply




Users browsing this thread: 17 Guest(s)