Sorry I try to keep up on the mailing list but missed this. I have been
reformatting some of my patches for official submission later this month
but I also handled many of these cases:
https://github.com/mitchcapper/gnulib/compare/master...ours_win_fsusage_fixes?w=1#diff-7e2438152a60cd739a4b33b7800e08161ab5dd86c8dacb54f0ae749c9bc4f818
This was to get much the same volume listing working ie for df:
```
Filesystem Size Used Avail Use% Mounted on
\Device\HarddiskVolume2 1.7T 781G 891G 47% M:\
\Device\HarddiskVolume6 4.0G 19M 3.9G 1% M:\sandbox\limit_mount\
\Device\HarddiskVolume5 931G 910G 21G 98% C:\
```
In terms of \\?\Volume\{GUID} paths its a bit tricky. It is true, a
volume not assigned or mounted to at least one drive letter or path, can
generally still be accessed with the volume guid syntax (gives new
definition to 'unmounted'). First its often not parsable by things setup
to handle paths. Windows native file open/save dialog does not work with
volume guid based paths. Application based support varies a decent bit.
You can often get an application to open with an absolute guid path for
example from run like
"notepad \\?\Volume{AB013c5f-9465-4225-nt32-orii80f3860d1}\out.txt" .
both powershell and windows command line generally don't work with volume
paths, but you can do some odd things. In a command window "dir
\\?\Volume{AB013c5f-9465-4225-nt32-orii80f3860d1}\" won't work but add an
additional slash "dir \\?\Volume{AB013c5f-9465-4225-nt32-orii80f3860d1}\\"
will. Running "start \\?\Volume{AB013c5f-9465-4225-nt32-orii80f3860d1}"
will open file explorer to your volume, and show the contents. Try to set
the address bar to a sub directory will fail. Entering the path directly
in explorer will fail. Launching it with two slashes at the end of it for
start (or from run) will fail. Some applications will work with volume
paths, but only if there is a path or drive letter also assigned it can
convert the path to.
Some windows API's will work just fine with volume paths as well.
Depending on sdks/language interfaces over native apis they may or may not
work.
Overall given the somewhat broken support across even first party
applications and UI's combined with the fairly rare need to access things
using volume ids, I generally think ignoring them is a fairly safe bet. It
could be returned as an additional piece of information (beyond existing
ids/serials) but I would assume limited application.
~mitch (they, them)
On Wed, Mar 19, 2025 at 9:31 AM Collin Funk <collin.fu...@gmail.com> wrote:
> Bruno Haible <br...@clisp.org> writes:
>
> > And with this patch, mount points other than the 26 drives are listed.
> > For example, I created a separate disk, formatted it as NTFS, mounted
> > it at S:\, added some files, unmounted it from S:\, and finally
> > mounted it at C:\Users\bruno\mt_scratch.
> >
> > The test program now reports:
> >
> > ??? C:\ ??? NFTS local
> > ??? P:\ C:\Users\Public NFTS local
> > ??? T:\ \\larid\tmp NTFS remote
> > ??? C:\Users\bruno\mt_scratch\ ??? NTFS local
>
> Thanks for the great improvement!
>
> > + /* Here we could use vol_name,
> something like '\\?\Volume{...}'. */
> > + me->me_devname = NULL;
> > + me->me_mntroot = NULL;
>
> I had the same thoughts about saving the \\?\Volume{...}, but wasn't
> sure how useful it was. A Windows expert can add it if is.
>
> Collin
>
>
