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

[R.Wieser]

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.

Regards,
Rudy Wieser

[VanguardLH]

Post by R.Wieser
Hello all,
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) ?
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.

[R.Wieser]

Vanguard,

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've yet to test that, but I'm assuming it changes. That doesn't matter
though, as I'm looking to uniquely identify the drive on my current 'puter.

In fact, not being able to find the drive (by its current GUID) on another
'puter might even be a good thing.

An alternate means of identifying a USB drive is to put a file
that is unique to that drive,

Yes, thats how I currently do it. Iterating thru all drives looking for
that particular file (and contents).

As you've discovered, UNCs are not to point at root folders of drives.

You could do worse than to explain how you hopped from a drive GUID to an
UNC ...

But yes, I also saw the similar behaviour.

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

Alas, I already tried that and it didn't work.

and FYI :

echo hello> \\?\Volume{guid}\bla.txt

works

del \\?\Volume{guid}\bla.txt

doesn't ("The parameter is incorrect").

IOW, its not really consistent.

I have not got an UNC available to check if it behaves the same.

Regards,
Rudy Wieser

[VanguardLH]

Post by R.Wieser
You could do worse than to explain how you hopped from a drive GUID to
an UNC ...

The syntax you cited is for UNC (Uniform Naming Convention) which is a
Microsoft-ism on Windows.

https://en.wikipedia.org/wiki/Path_(computing)#Universal_Naming_Convention
https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#unc-paths
https://www.lifewire.com/unc-universal-naming-convention-818230
and more online articles

Post by R.Wieser
Alas, I already tried [.. for parent folder] and it didn't work.

I expected that moving back from the resource pointer wouldn't work, but
it's a shot worth trying.

[R.Wieser]

Vanguard,

Post by VanguardLH
The syntax you cited is for UNC (Uniform Naming Convention) which
is a Microsoft-ism on Windows.

I know.

The thing is that because it looked like an UNC you decided it must be one.

... which, from the rest of my previous post, you can see it isn't.

Post by VanguardLH
I expected that moving back from the resource pointer wouldn't work,
but it's a shot worth trying.

:-) Which is why I tried it (before starting this thread) myself.

Regards,
Rudy Wieser

[VanguardLH]

Post by R.Wieser
Vanguard,

Post by VanguardLH
The syntax you cited is for UNC (Uniform Naming Convention) which
is a Microsoft-ism on Windows.

The thing is that because it looked like an UNC you decided it must be one.
... which, from the rest of my previous post, you can see it isn't.

When in your first or subsequent posts did you not use UNC syntax?

[R.Wieser]

Vanguard,

Post by VanguardLH

Post by R.Wieser
... which, from the rest of my previous post, you can see it
isn't.

When in your first or subsequent posts did you not use UNC
syntax?

:-) No kid, I'm not going to play that game with you. *you* claim, *you*
underbuild it.

In this case why you think that I used UNC syntax. After that we can
continue our conversation.

Regards,
Rudy Wieser

[VanguardLH]

Post by R.Wieser
Vanguard,

Post by VanguardLH

Post by R.Wieser
... which, from the rest of my previous post, you can see it
isn't.

When in your first or subsequent posts did you not use UNC
syntax?

:-) No kid, I'm not going to play that game with you. *you* claim, *you*
underbuild it.
In this case why you think that I used UNC syntax. After that we can
continue our conversation.

You chose to exclude the articles already present on UNC syntax. If
you're going to lie about the syntax, don't bother continuing to deny
the syntax you ARE using.

[Kerr-Mudd, John]

On Fri, 3 May 2024 02:22:55 -0500

Post by VanguardLH

Post by R.Wieser
Vanguard,

Post by VanguardLH

Post by R.Wieser
... which, from the rest of my previous post, you can see it isn't.

When in your first or subsequent posts did you not use UNC
syntax?

:-) No kid, I'm not going to play that game with you. *you* claim, *you*
underbuild it.
In this case why you think that I used UNC syntax. After that we can
continue our conversation.

You chose to exclude the articles already present on UNC syntax. If
you're going to lie about the syntax, don't bother continuing to deny
the syntax you ARE using.

No fighting in the war room!

[R.Wieser]

Vanguard,

Post by VanguardLH
You chose to exclude the articles already present on UNC syntax. If
you're going to lie about the syntax, don't bother continuing to deny
the syntax you ARE using.

:-) No kid, I'm not going to play that game with you. *you* claim, *you*
underbuild it.

Regards,
Rudy Wieser

[VanguardLH]

Post by R.Wieser
Vanguard,

Post by VanguardLH
You chose to exclude the articles already present on UNC syntax. If
you're going to lie about the syntax, don't bother continuing to deny
the syntax you ARE using.

:-) No kid, I'm not going to play that game with you. *you* claim, *you*
underbuild it.

Yep, ignore the articles already given. Try searching on UNC or Uniform
Naming Convention Windows. Here's more articles you'll ignore, because
it conflicts with your contention that you're not using UNC syntax:

https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
Naming Conventions (3rd bullet)
Fully Qualified vs. Relative Paths ("A UNC name ...")

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/62e862f4-2a51-452e-8eeb-dc4ff5ee33cc
(shows the UNC syntax already mentioned)

So, just WHAT syntax do *you* think you are using? Let us see just what
you can contrive that contradicts what you show.

[R.Wieser]

Vanguard,

Post by VanguardLH
https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
Naming Conventions (3rd bullet)
Fully Qualified vs. Relative Paths ("A UNC name ...")

Thank you. The above one sure looks like it supports your stance in that a
volume GUID used like I showed conforms to the UNC specs.

Now we can continue with my "if its an UNC than why doesn't it behave like
one ?" remark/question - like also in the subjectline / initial post
ofcourse.

Regards,
Rudy Wieser

[VanguardLH]

Post by R.Wieser
Vanguard,

Post by VanguardLH
https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
Naming Conventions (3rd bullet)
Fully Qualified vs. Relative Paths ("A UNC name ...")

Thank you. The above one sure looks like it supports your stance in that a
volume GUID used like I showed conforms to the UNC specs.
Now we can continue with my "if its an UNC than why doesn't it behave like
one ?" remark/question - like also in the subjectline / initial post
ofcourse.

Comes back to the UNC pointing to the shared resource on a host, like a
folder, not to the drive itself. In fact, you can also anchor File
Explorer to a folder on a drive as the "root", like:

explorer.exe /root,c:\temp

However, with File Explorer, it reads the file system, so it can find
the root of the drive rather than the root specified for the object
(folder). When using a UNC, you are also specifying the root object as
the shared resource (folder). While we Windows users have used "root"
to mean the root folder of a drive, "root" also means whatever anchor
you specify. You can also specify the root object of a mount point as a
folder.

https://learn.microsoft.com/en-us/windows-server/storage/disk-management/assign-a-mount-point-folder-path-to-a-drive

I haven't used this, but I suspect you cannot move back of the mount
point, either, just like with a UNC. The mount point is the root
specified, like a folder object.

Perhaps the underlying issue you're trying to resolve is the drive
letter assignment for a USB drive can change. One time you plug it in,
and it's drive F:, but another time it's G:, because something plugged
in already had F: assigned to it. While I've not used it, I've seen the
following recommended in trying to manage USB drive letter assignments
where you can try to keep the same drive letter to the same USB drive:

https://www.uwe-sieber.de/usbdlm_e.html

Seems a bit cumbersome, but some folks want or need fixed USB drive
letters. When I needed to find a USB drive regardless of its drive
letter, I did the for-loop script method in a batch file of looking for
the fingerprint file. No having to install more software to compensate
for variable USB drive letters, but I do have to manage the fingerprint
files on multiple USB drives. You could also use unique volume IDs,
too, on which to scan, or a combo of volume ID and fingerprint file.
For scripts, I use a fingerprint file to identify the targeted USB
drive. I mostly use unique volume IDs for my own recognition of which
drive (internal or removable) is for what use, but I do make the volIDs
unique.

[R.Wieser]

Vanguard,

Post by VanguardLH
Comes back to the UNC pointing to the shared resource on a host,
like a folder, not to the drive itself.

Nope.

As mentioned, I can redirect output to "\\?\Volume{guid}\bla.txt"*. But I
can't, using the same filespec, do a "del" on that file afterwards.

* and yes, the file is created in the root of the drive, as a "dir \bla.txt"
shows.

So yes, an "\\?\Volume{guid}\" specifies the drive itself.

... but not always. And *thats* the problem.

Any idea why and/or how to fix that ?

Regards,
Rudy Wieser

[VanguardLH]

Post by R.Wieser
Vanguard,

Post by VanguardLH
Comes back to the UNC pointing to the shared resource on a host,
like a folder, not to the drive itself.

Nope.
As mentioned, I can redirect output to "\\?\Volume{guid}\bla.txt"*. But I
can't, using the same filespec, do a "del" on that file afterwards.
* and yes, the file is created in the root of the drive, as a "dir \bla.txt"
shows.
So yes, an "\\?\Volume{guid}\" specifies the drive itself.
... but not always. And *thats* the problem.
Any idea why and/or how to fix that ?
Regards,
Rudy Wieser

Weird scenario: can create at root, but cannot delete at root. Guess a
UNC won't work for you. However, seems the UNC syntax you use is
invalid as it is supposed to point to a shared resource, like a folder.
Looks like you found a loophole.

As an experiment, I ran mountvol to get the GUID for the C: drive. For
me, that is \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\. I then
used Win+R to open the Run dialog, and pasted in that exact string.
File Explorer opened to the root of the drive, but shows as "Windows 10
(\:)" instead of "Windows 10 (C:\)". The volume ID of my C: drive is
"Windows 10". In an admin command shell, I entered:

echo hello > \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt

a 'dir' on C:\ shows the testme.txt file showed up in the root folder of
C:\. I then tried:

del \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt

and got "The parameter is incorrect". Seems a parsing issue, perhaps on
the "?" host placeholder in the UNC. I then tried with double quotes:

del "\\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt"

Argh, still got incorrect parameter. 'erase' failed, too. 'move'
failed, too (thinking I might move into a temp folder to then delete the
temp folder along with all files under there). Yet:

copy \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\TEMP

worked (1 file copied).

Thinking I might assign a drive letter to the GUID for the drive, I
tried:

subst f: \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}

F: had not yet been assigned. I got "Path not found - <GUID>".

Reminds me of way back when I found parsing by DOS commands was not
consistent, like each DOS command was created by a different programmer.
I didn't find an arg to 'xcopy' that would move and delete, or just
delete to see if parsing was better in that tool.

I tried using robocopy.exe with /MOV to move the test file into a temp
folder and delete the source file, and then rerun robocopy with /PURGE
to eliminate files in the destination that no longer existed in the
source, like (the lines are long due to using UNC and GUIDs):

robocopy /mov \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\TEMP
robocopy /purge \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\TEMP

Nope, the first robocopy (to move and delete) failed with:

ERROR 53 (0x00000035) Accessing Source Directory \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt\
The network path was not found.

Well, shit, I got the syntax wrong. According to "robocopy /?", the
source is a directory (folder), not a file. I don't want to move and
then delete everything in the root folder. So, I changed to (and
crossed my fingers hoping not to have to restore from an image backup):

robocopy \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\ \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\TEMP testme.bat /mov

That failed with:

ERROR 53 (0x00000035) Accessing Source Directory \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\
The network path was not found.

Doesn't work with the root folder of the GUID identified drive. Again
back to having to specify a folder as the shared resource (root) in the
UNC path. The DOS commands won't work. Redirecting stdout with echo
probably entails using system file I/O API calls that will work as you
noted, but the DOS commands don't like accessing the root of a drive
using its GUID.

Just doesn't seem the DOS commands (those inside of cmd.exe) will let
you reliably use UNC pathing containing GUIDs. Those DOS commands were
pre-UNC era, and pre-GUID era. They don't understand the later stuff.

Maybe you'll have to switch from a batch file (.bat or .cmd) using DOS
commands to using a Powershell script. I haven't bothered yet to learn
Powershell, so I relegate expertise to online articles I find, like:

https://www.howtogeek.com/delete-files-and-folders-with-powershell/

Maybe the path arg can use UNC pathing with GUIDs. That article
presumes a single arg is for the path to the object (file or folder).
More syntax on the Remove-Item cmdlet is mentioned at:

https://www.sharepointdiary.com/2020/12/powershell-delete-file.html

Inside of the Powershell shell, I tried (with and without "-path"):

remove-item -path "\\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt"

No error was reported, but the file did not get deleted. del is an
alias to remove-item cmdlet, so I tried in Powershell:

del C:\testme.txt

That failed with "cannot remove" and "access to path denied". I tried
some other commands, and even moved into the C:\TEMP folder to try
deleting from there, but gave up on the PS errors.

[VanguardLH]

Post by VanguardLH

Post by R.Wieser
Vanguard,

Post by VanguardLH
Comes back to the UNC pointing to the shared resource on a host,
like a folder, not to the drive itself.

Nope.
As mentioned, I can redirect output to "\\?\Volume{guid}\bla.txt"*. But I
can't, using the same filespec, do a "del" on that file afterwards.
* and yes, the file is created in the root of the drive, as a "dir \bla.txt"
shows.
So yes, an "\\?\Volume{guid}\" specifies the drive itself.
... but not always. And *thats* the problem.
Any idea why and/or how to fix that ?
Regards,
Rudy Wieser

Weird scenario: can create at root, but cannot delete at root. Guess a
UNC won't work for you. However, seems the UNC syntax you use is
invalid as it is supposed to point to a shared resource, like a folder.
Looks like you found a loophole.
As an experiment, I ran mountvol to get the GUID for the C: drive. For
me, that is \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\. I then
used Win+R to open the Run dialog, and pasted in that exact string.
File Explorer opened to the root of the drive, but shows as "Windows 10
(\:)" instead of "Windows 10 (C:\)". The volume ID of my C: drive is
echo hello > \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt
a 'dir' on C:\ shows the testme.txt file showed up in the root folder of
del \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt
and got "The parameter is incorrect". Seems a parsing issue, perhaps on
del "\\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt"
Argh, still got incorrect parameter. 'erase' failed, too. 'move'
failed, too (thinking I might move into a temp folder to then delete the
copy \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\TEMP
worked (1 file copied).
Thinking I might assign a drive letter to the GUID for the drive, I
subst f: \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}
F: had not yet been assigned. I got "Path not found - <GUID>".
Reminds me of way back when I found parsing by DOS commands was not
consistent, like each DOS command was created by a different programmer.
I didn't find an arg to 'xcopy' that would move and delete, or just
delete to see if parsing was better in that tool.
I tried using robocopy.exe with /MOV to move the test file into a temp
folder and delete the source file, and then rerun robocopy with /PURGE
to eliminate files in the destination that no longer existed in the
robocopy /mov \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\TEMP
robocopy /purge \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\TEMP
ERROR 53 (0x00000035) Accessing Source Directory \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt\
The network path was not found.
Well, shit, I got the syntax wrong. According to "robocopy /?", the
source is a directory (folder), not a file. I don't want to move and
then delete everything in the root folder. So, I changed to (and
robocopy \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\ \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\TEMP testme.bat /mov
ERROR 53 (0x00000035) Accessing Source Directory \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\
The network path was not found.
Doesn't work with the root folder of the GUID identified drive. Again
back to having to specify a folder as the shared resource (root) in the
UNC path. The DOS commands won't work. Redirecting stdout with echo
probably entails using system file I/O API calls that will work as you
noted, but the DOS commands don't like accessing the root of a drive
using its GUID.
Just doesn't seem the DOS commands (those inside of cmd.exe) will let
you reliably use UNC pathing containing GUIDs. Those DOS commands were
pre-UNC era, and pre-GUID era. They don't understand the later stuff.
Maybe you'll have to switch from a batch file (.bat or .cmd) using DOS
commands to using a Powershell script. I haven't bothered yet to learn
https://www.howtogeek.com/delete-files-and-folders-with-powershell/
Maybe the path arg can use UNC pathing with GUIDs. That article
presumes a single arg is for the path to the object (file or folder).
https://www.sharepointdiary.com/2020/12/powershell-delete-file.html
remove-item -path "\\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt"
No error was reported, but the file did not get deleted. del is an
del C:\testme.txt
That failed with "cannot remove" and "access to path denied". I tried
some other commands, and even moved into the C:\TEMP folder to try
deleting from there, but gave up on the PS errors.

Argh, after closing this thread and moving on, I tried to delete the
textme.txt file using File Explorer. It reported that I needed admin
privs to delete. Huh? Somehow the file got permissions on it that I
had not intended. Recreated the file:

echo hello there >
\\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt

That created the file. Then I attempted to delete the test file in File
Explorer, and got the prompt for admin priv again. Then I did:

echo hello there > C:\testme.txt

and a delete gave the admin prompt again. However, I'm on Windows 10,
so there may be protections there not back in Windows XP. If I change
to the C:\TEMP folder, and do the 2nd echo command, no admin prompt to
delete. So, I tried the UNC w/GUID echo command, but with a folder in
the UNC path, as in:

echo hello there > \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\temp\testme.txt

No admin prompt to delete the file. In PS, the remove-item cmdlet
worked, too. Something about files at the root level of a drive (for
the OS partition) in Windows 10 that is different than I remember in
prior Windows versions.

So, you could try Powershell, but is that available back in WinXP (one
of the newsgroups to which you cross-posted). I don't know about UNC
support in old versions of Windows.

[AugustA]

On Sat, 4 May 2024 04:16:15 -0500
VanguardLH <***@nguard.LH> wrote:

V> Argh, after closing this thread and moving on, I tried to delete the
V> textme.txt file using File Explorer. It reported that I needed admin
V> privs to delete. Huh? Somehow the file got permissions on it that I
V> had not intended. Recreated the file:
V>
V> echo hello there >
V> \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\testme.txt
V>
V> That created the file. Then I attempted to delete the test file in File
V> Explorer, and got the prompt for admin priv again. Then I did:
V>
V> echo hello there > C:\testme.txt
V>
V> and a delete gave the admin prompt again. However, I'm on Windows 10,
V> so there may be protections there not back in Windows XP. If I change
V> to the C:\TEMP folder, and do the 2nd echo command, no admin prompt to
V> delete. So, I tried the UNC w/GUID echo command, but with a folder in
V> the UNC path, as in:
V>
V> echo hello there > \\?\Volume{19b786f1-f8cd-4b0c-b51e-66c63d0c3f7e}\temp\testme.txt
V>
V> No admin prompt to delete the file. In PS, the remove-item cmdlet
V> worked, too. Something about files at the root level of a drive (for
V> the OS partition) in Windows 10 that is different than I remember in
V> prior Windows versions.

Could you delete the \temp folder? Maybe not, if the folder contains files?

Can you delete an empty folder?

My guess is that there are simply some protections built-in so as not accidentally delete stuff at root level.

[R.Wieser]

August,

Post by AugustA
Can you delete an empty folder?

You can "md" and "rd" folders . You can create a file thru redirection and
thru redirection also read from it.

"dir", "del" and "attrib" (the other few that I have tested) throw an error.

In a program using a volume guid as argument to FindFirstFile (kernel32)
works.

Yep, its a bit of a mess.

Regards,
Rudy Wieser

[R.Wieser]

Vanguard,

Post by VanguardLH
Weird scenario: can create at root, but cannot delete at root.

Somewhat : I cannot delete a *file* at root. Creating and deleting a
*folder* doesn't seem to be a problem.

Post by VanguardLH
However, seems the UNC syntax you use is invalid as it is supposed
to point to a shared resource, like a folder. Looks like you found
a loophole.

I have a different POV : that volume guid(s usage) never was an UNC, and you
just assumed it had to be.

https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mountvol

Take a look at the example provided in the above. You might notice that it
*doesn't* include a foldername after the volume guid part. And mind you :
thats MS own information.

Post by VanguardLH
As an experiment, I ran mountvol to get the GUID for the C: drive.

[snip experiments]

Your tests confirm the ones I did.

Funny that your Win10, several versions after my own WinXP, still has the
same "loopholes" :-)

Regards,
Rudy Wieser

[AugustA]

On Wed, 1 May 2024 18:13:56 -0500
VanguardLH <***@nguard.LH> wrote:

V> set fileid=USB29072.id
V> for /f %i in (`fsutil fsingo drives`) do
V> if exist (%i%%fileid%) set targdrv = %i
V>
V> Note: Within batch files, double the percent sign on vars, like %%i.
V> The %fileid% var doesn't need doubled percents.
V>
V> That's just off the top of my head without any testing of syntax or
V> results. [...]

fsinfo, not fsingo. :D

This would have been handy in the past. Interesting.

[Zaidy036]

Post by R.Wieser
Hello all,
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) ?
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.
Regards,
Rudy Wieser

This is what I use on Win 10 where xxxxx is the assigned name:

FOR /f %%D IN ('WMIC VOLUME GET DRIVELETTER^, LABEL ^| FIND "xxxxx"') DO
SET "_HD=%%D"

[R.Wieser]

Zaidy036,

Post by Zaidy036
FOR /f %%D IN ('WMIC VOLUME GET DRIVELETTER^, LABEL ^| FIND "xxxxx"') DO
SET "_HD=%%D"

Thank you.

Regards,
Rudy Wieser

[VanguardLH]

Post by Zaidy036

Post by R.Wieser
Hello all,
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) ?
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.

FOR /f %%D IN ('WMIC VOLUME GET DRIVELETTER^, LABEL ^| FIND "xxxxx"') DO
SET "_HD=%%D"

I'll have to remember using wmic. In a similar for-loop, I use fsutil.

[JJ]

Post by R.Wieser
Hello all,
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) ?
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.
Regards,
Rudy Wieser

Without additional software, the only way is to assign a drive letter to the
mount point path, and access the root using the drive letter.

Without using a drive letter, junction or symlink (Symbolic Link) in NTFS
drive which point to the mount point path can be used. Access the
junction/symlink to access the mount point root. But in Windows XP,
additional software is needed for creating junction/symlink, since Windows
XP doesn't have any built in tool for it (Vista+ already have it).

I believe GNU has a tool for creating junction/symlink, but I don't know the
name of the tool. Alternatively, there's a freeware named "Symlink" which
can create junction/symlink. Japanese made, but the software is in English.

https://emk.name/#download

But in Windows XP, symlink functionality will need the provided driver
(which is only available in 32-bit). Windows XP doesn't need additional
driver for junction functionality, so junction can simply be used instead of
symlink.

[R.Wieser]

JJ,

Post by JJ
Without additional software, the only way is to assign a drive letter
to the mount point path, and access the root using the drive letter.

[snip]

I'll just have to remember that using the root of a drive thru a volume guid
from a commandline (cmd.exe) isn't going to happen.

Though I think I should consider myself lucky that it allows me access to
any contents of a subdirectory in such a root - as long as I know its name
ofcourse. :-)

Odd that parts of the commandline accept it, but others do not. :-|

Post by JJ
But in Windows XP, additional software is needed for creating
junction/symlink, since Windows XP doesn't have any built in tool
for it

It looks like "mountvol" does (something like?) that (the same program wich
displays all volume guids).

Thanks for the info.

Regards,
Rudy Wieser

[AugustA]

On Sat, 4 May 2024 17:57:28 +0200
"R.Wieser" <***@is.invalid> wrote:

RW> It looks like "mountvol" does (something like?) that (the same program wich
RW> displays all volume guids).

Interesting. I didn't know that mountvol existed. Running it without paramaters seems to report the current mount points for all drives. Could be handy.