public inbox for cygwin-patches@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-patches@cygwin.com
Subject: Re: [PATCH] Cygwin: Add /dev/disk/by-drive and /dev/disk/by-uuid symlinks
Date: Thu, 16 Nov 2023 13:19:53 +0100	[thread overview]
Message-ID: <ZVYI6QQ+zOB2KCPy@calimero.vinschen.de> (raw)
In-Reply-To: <d4cd305a-1a23-633b-3327-6ec01cf462b6@t-online.de>

On Nov 16 12:50, Christian Franke wrote:
> Corinna Vinschen wrote:
> > Hi Christian,
> > 
> > On Nov 15 18:23, Christian Franke wrote:
> > > This is the next (and possibly last for now) extension to the /dev/disk
> > > directory. Limited to disk related entries which allowed a straightforward
> > > extension of the existing code.
> > > 
> > > My original idea was to add also other drive letters and volume GUIDs. Too
> > > complex for now.
> > > 
> > > Interestingly the volume GUID (by-uuid) for partitions on MBR disks is
> > > sometimes identical to the partition "GUID" (by-partuuid), sometimes (always
> > > for C:?) not. With GPT disks, both GUIDs are possibly always identical.
> > That looks great, but in terms of by-uuid, I'm not sure it's the
> > right thing to do.  On Linux I have a vfat partition (/boot/efi).
> > The uuid in /dev/disk/by-uuid is the volume serial number, just
> > with an extra dash, i.e.
> > 
> >    057A-B3A7 -> ../../sda1
> > 
> > That's what you get for FAT/FAT32/exFAT.
> 
> What is the best way to retrieve a FAT* serial? There is
> GetVolumeInformation{ByHandleW}(), but this may not work with the NT Layer
> pathnames / handles used here.

It will work, because Windows and NT handles are the same thing as long
as you created the handle using an operation opening kernel objects, as,
for instance, files or volumes.

Actually, GetVolumeInformation() is the combination of multiple
NtQueryVolumeInformationFile calls.  The call retrieving the
serial number is NtQueryVolumeInformationFile(..., FileFsVolumeInformation),
as is used in fs_info::update, mount.cc, line 250 ATM.

> > I also tried an NTFS partition and the output looks like this:
> > 
> >    0FD4F62866CFBF09 -> ../../sdc1
> > 
> > This is the 64 bit volume serial number as returned by
> > DeviceIoControl(FSCTL_GET_NTFS_VOLUME_DATA)(*).
> > 
> > Wouldn't that be what we want to see, too?
> 
> Hmm...... yes. Should both information be provided in by-uuid or only the
> serial numbers? In the latter case, should we add e.g. by-voluuid for the
> volume GUIDs ?

Good question... by-voluuid sounds like a nice idea.  It's a Windows-only
concept anyway, so it might make sense to present it in its own directory.


Corinna

  reply	other threads:[~2023-11-16 12:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-15 17:23 Christian Franke
2023-11-16 10:36 ` Corinna Vinschen
2023-11-16 11:50   ` Christian Franke
2023-11-16 12:19     ` Corinna Vinschen [this message]
2023-11-16 17:02       ` Christian Franke
2023-11-17 12:11         ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZVYI6QQ+zOB2KCPy@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin-patches@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).