Re: RFE: mount support for device UUID's

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Oct 10 23:00, Mark O'Keefe wrote:
> On 10/10/2012, at 9:20 PM, Corinna Vinschen wrote:
> > On Oct 10 17:42, Mark O'Keefe wrote:
> >> On 09/10/2012, at 7:53 PM, Corinna Vinschen wrote:
> >>> On Oct  4 10:47, Mark O'Keefe wrote:
> >>>> [...]
> >>> Ok.  But Linux UUIDs for fixed disks are equivalent in layout to Windows
> >>> UUIDs/GUIDs.  So why not just use the GUID "as is"?
> >> 
> >> The Windows UUIDs/GUIDs can change (though that isn't common and I
> >> believe does require a specific user action to cause it).
> > 
> > The Linux UUIDs can change as well, see tune2fs(1).
> > 
> >> Also, 
> >> they aren't consistent with the result of running blkid.  If using
> >> UUID in mount you would expect it to match the blkid output.
> > 
> > I wasn't even aware of blkid in the utils-linux package so far.  It's
> > quite a bummer that libblkid already uses a mechanism which generates
> > other GUIDs than the ones in the native NT namespace.
> > 
> > The other problem with the libblkid approach is that you have to have
> > admin rights to access the values.  This is neither the case under
> > Linux, nor with the GUID values used by the Windows volume manager.
> [...]
> Would it be more appropriate to have a GUID instead of UUID extension
> as described above?  Have a new tool which provides information to
> help users determine which drives map to which GUID's?  Don't confuse
> the issue by calling it UUID and clashing with blkid.  Call it what it
> is - the Windows GUID.  Same concept, but different identifier.  Fits
> with cygwin and provides the functionality with what is there already.

Hang on.  This won't go into Cygwin 1.7.17 anyway, so we still have some
time to discuss this stuff and to create a nice solution.

I just made some tests and it looks like all information is available
without requiring admin rights.

Here's what libblkid does (apart from other methods which are not
feasible on Windows).  It opens the partition for reading and tries to
access the superblock info.  This only works for admins on Windows.

The information taken for the UUID value is the 8 byte
VolumeSerialNumber on NTFS and the 4 byte serial number on all FAT
variations.  ReFS isn't handled yet by blkid, so we're free to do as we
like, for instance, just using the serial number as on FAT.  CD-ROMs and
DVDs apparently don't have a UUID, so they can be ignored.

The 8 byte NTFS VolumeSerialNumber can be read without admin rights by
using the NtFsControlFile(FSCTL_GET_NTFS_VOLUME_DATA) call.  For the
returned data structure, see
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365256%28v=vs.85%29.aspx

The serial number for FAT and ReFS handling can be read without admin
rights by NtQueryVolumeInformationFile(FileFsVolumeInformation), as
it's already done in fsinfo::update in mount.cc.

So, here's a vague idea for a start.  If we see a UUID= entry in
the fstab file, we scan the native \Device directory for
"HarddiskVolumeXXX" devices(*).  For each such device, open it with
minimal rights and call NtFsControlFile(FSCTL_GET_NTFS_VOLUME_DATA).
If this works, it's an NTFS drive and we have the UUID.  If it
fails, call NtQueryVolumeInformationFile(FileFsVolumeInformation)
and use the serial number as UUID.  If the UUIDs match, we have our
device path and we can create the mount point from here.

Note that the latter part, creating a mount point using the native
device path, doesn't work yet at all.  This has to be implemented
as well.

(*) Alternatively we scan the \Device\HarddiskX\PartitionY entries
    as we do in format_proc_partitions in fhandler_proc.cc.  This also
    provides a direct connection between the UUID and the Cygwin /dev/sdXY
    device.
    
    Having said that, a slightly tweaked format_proc_partitions would
    also allow to implement a virtual /dev/disk/by-uuid directory with
    not too much effort.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat