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

"R.Wieser" <[email protected]> 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.