Posts: 64
Threads: 21
Joined: Apr 2022
Reputation:
2
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.
Posts: 64
Threads: 21
Joined: Apr 2022
Reputation:
2
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.
Posts: 90
Threads: 2
Joined: Apr 2023
Reputation:
2
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.
Posts: 64
Threads: 21
Joined: Apr 2022
Reputation:
2
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.
Posts: 64
Threads: 21
Joined: Apr 2022
Reputation:
2
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.
Posts: 64
Threads: 21
Joined: Apr 2022
Reputation:
2
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.