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.
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?
An alternate means of identifying a USB drive is to put a file
that is unique to that drive,
As you've discovered, UNCs are not to point at root folders of drives.
Since the simplest form is \\server\path, maybe (just a guess) you
could use the relative pathing of ".." to refer back a directory level,
You could do worse than to explain how you hopped from a drive GUID to
an UNC ...
Alas, I already tried [.. for parent folder] and it didn't work.
The syntax you cited is for UNC (Uniform Naming Convention) which
is a Microsoft-ism on Windows.
I expected that moving back from the resource pointer wouldn't work,
but it's a shot worth trying.
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
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"
On 5/1/2024 7:03 AM, R.Wieser 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.
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"
Vanguard,
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.
... 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?
Vanguard,
... 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.
"R.Wieser" <[email protected]d> wrote:
Vanguard,
... 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.
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.
Vanguard,
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.
https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
Naming Conventions (3rd bullet)
Fully Qualified vs. Relative Paths ("A UNC name ...")
Vanguard,
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.
Vanguard,
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
"R.Wieser" <[email protected]d> wrote:
Vanguard,
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.
Weird scenario: can create at root, but cannot delete at root.
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.[snip experiments]
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
Without additional software, the only way is to assign a drive letter[snip]
to the mount point path, and access the root using the drive letter.
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).
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. [...]
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.
Can you delete an empty folder?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 160:07:50 |
| Calls: | 12,094 |
| Calls today: | 2 |
| Files: | 15,000 |
| Messages: | 6,517,761 |