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

VanguardLH <[email protected]> wrote:

> "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.

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.