Re: use a drives guid instead of its letter - where is the drive root ?

"R.Wieser" <[email protected]> wrote:

> Hello all,
> 
> Using XPsp3 :
> 
> I have an USB drive, which I want to refer to by its guid - so that if its 
> drive letter changes (because of other USB drives) I can still dependently 
> talk to it (from within a script).
> 
> The thing is, when I use the result of "mountvol.exe" I can access the 
> contents of any folder on the drive, but not the contents of its root.
> 
> Question: what do I have to write/do to access its root (do a "dir" on it) ?
> 
> Reference:
> 
> https://superuser.com/questions/465730/access-to-a-disk-drive-using-volume-id-instead-of-a-drive-letter-in-windows
> 
> In the above the "start \\?\Volume{guid}\" method to open the drive doesn't 
> work for me. However, "start \\?\Volume{guid}\foldername" does.

An alternate means of identifying a USB drive is to put a file that is
unique to that drive, like USBxxxxxxxx.id.  The USB is just a reminder
that it is a USB-attached drive, but you don't need to use that.  The
xxxxxxxx string is whatever would be unique for a filename on each USB
drive where you created the file.  It is just a file, so the .id
extension means nothing to the OS.  It is just a reminder to you what
the file is for.  Doesn't matter what is inside the file: text, binary,
doc, or just a blank/empty file.  Your script would look for the unique
filename on all drives, and select the one where the file was found (and
in the root folder, too).  Use a var to specify the drive's root folder,
and use a for-loop to walk through every drive letter to find the unique
file for the removable drive you are looking for.  Without digging into
testing a for-loop, my guess is you'd use "for /f ["options"]" syntax to
parse the output of a DO on a 'dir' command looking for the unique file.
You parse through the output of "fsutil fsinfo drives" which lists all
the mounted drives by their letter assignments.  Maybe:

set fileid=USB29072.id
for /f %i in (`fsutil fsingo drives`) do 
  if exist (%i%%fileid%) set targdrv = %i
  
Note: Within batch files, double the percent sign on vars, like %%i.
The %fileid% var doesn't need doubled percents.
  
That's just off the top of my head without any testing of syntax or
results.  The fsutil command is enclosed in backquotes which means to
run the command, and pipe its stdout as the string to walk through by
the for-loop.  Since the stdout of fsutil puts out "drives: ", the first
check would fail, but the for-loop walks through the rest of stdout to
find the drive letters.

Sorry, I've not used the GUID of a drive to identify it in a UNC.  Is
the GUID assigned to a drive under one instance of the OS that same GUID
that gets assigned to the same drive under different instances of the
OS?  I'm probably thinking of V1 GUIDs that embed the MAC address of the
host which means a GUID for the same drive would be different on
differen hosts since the different hosts have different MACs.

http://guid.us/

There is no central GUID assignment authority to guarantee GUIDs are the
same across all hosts.  From what I've read, GUIDs are very likely to be
unique, they are not guaranteed to be unique, but the possibility of
GUID conflict is very small.

As you've discovered, UNCs are not to point at root folders of drives.
They point at a network resource in a local-area network (LAN), like a
shared file, directory (folder), or printer.  They have the syntax:

\\<hostname>[@SSL][@PORT]\<sharedfolder>\<resource>
or
\\?\UNC\<hostname>\<sharedfolder>\<resource>
or
\\<hostname>\<sharedresource>

Since the simplest form is \\server\path, maybe (just a guess) you could
use the relative pathing of ".." to refer back a directory level, like:

\\<server>\<guid>\..\<file>
or
\\?\<guid>\<file>

but I suspect that attempts to walk outside the GUID mount point.

https://www.minitool.com/lib/unc-path.html
Within a UNC path, the filename refers to a local subdirectory beneath
the share section. This portion is optional. When file name is
specified, the UNC path simply points to the top-level folder of the
share.

The filespec would be after the sharedresource object.  I don't think
you can specify the root folder using the GUID.  You can by using mapped
drives as the sharedresource object, like \\?\c:\file.  But if you're
stuck using mapped drive letters, you might as well use the script to
find a unique file on a mounted drive to determine which is the one on
which you want to focus.

I know you don't want solutions that don't perfectly match on your
expectation or wants, so I'm not going to bother writing and debugging a
script to find a uniquely named file on each mounted drive.  I'll let
you do that, but you probably won't since it is not exactly what you
want.