RFE: mount support for device UUID's

Corinna Vinschen corinna-cygwin@cygwin.com
Tue Oct 9 08:54:00 GMT 2012

Hi Mark,

On Oct  4 10:47, Mark O'Keefe wrote:
> Hi all,
> I'm new to this list so not entirely sure of the protocol, but I'd like to suggest an enhancement

...not a protocol as such, but it would be nice if you could restrict
the number of chars per line to somewhat below 80 :-}

> to the mount capabilities of cygwin.  I would guess I'm not the only one who plugs various
> external drives into my PC and would like to predictably define where they get mounted
> under cygwin.  At the moment this is limited to just the drive letter (which can change).  I
> would like your thoughts on an enhancement which allowed the use of the drive UUID to
> identify the connected drive letter, ie., make the drive letter dynamic.  The intent is to add
> an optional parameter to fstab to support UUID.

In contrast to a mount table on a "real" UNIX, the Cygwin mount table is
just the mapping from an arbitrary Windows path to an arbitrary POSIX
path.  Devices don't count in this picture, not even really for the
cygdrive mapping since DOS drive letters are NOT devices but paths in
the first place.  From this point of view, using a UUID based approach
to access drives is quite a change from the usual approach.

Having said that, I see how a new approach to access removable drives
this way could be useful.

> [...]
> To cut to the chase, I've created a version which leverages aspects of the /proc virtual
> filesystem, behaviours of Windows, blkid and the special file names of cygwin.
> When a drive is first attached to Windows it creates a unique GUID for that drive.  This does
> not change (unless you deliberately delete these from the registry).  These unique
> references appear in the /proc filesystem as:  /proc/sys/GLOBAL??/Volume{GUID}
> These are links to the device under /proc/sys/Device
> Also under the /proc filesystem are the drive letter references:
> /proc/sys/GLOBAL??/[A-Z]:
> These link to the device under /proc/sys/Device also.


> So, you can map a unique device GUID to a drive letter dynamically using this information.
> Now to get the UUID into the picture.
> If you had a script which populated the UUID as a link to the unique volume you can map
> the UUID to a drive letter dynamically by expanding the links at run-time.
> /dev/disk/by-uuid/<UUID>    =>    /dev/sys/GLOBAL??/Volume{<GUID>}
> /dev/sys/GLOBAL??/Volume{<GUID>}    =>    /dev/sys/Device/<device>
> /dev/sys/Device/harddisk[0-9]*/partition[0-9]*    =>    /dev/sys/Device/<device>

Uh, hang on.  You meant /proc/sys/..., right?  You are not suggesting
another redirection via a not yet existing /dev/sys/... I hope?

> http://www.cygwin.com/cygwin-ug-net/using-specialnames.html
> Provides the mapping of POSIX device name to Internal NT device name  (3rd line above).
> So, using this you can take the output of blkid and get a valid mapping to the various
> components required above.
> You can use a bootstrap process to create the /dev/disk/by-uuid/<UUID> link for each
> of your devices the first time you attach them (manual process) and after this rely on
> the /proc filesystem to reliably map a connected UUID drive to the mapped drive letter.
> You can also rely on this to determine if it is connected as the /proc filesystem only shows
> the links for connected devices, so while the /dev/disk/by-uuid link is permanent, the
> destination only exists if the drive is mounted.

...which is kind of weird, considering that Linux /dev/disk/... only
contains drive information for connected drives as well...

> Sample directory listings:
> $ ls -l /dev/disk/by-uuid
> total 6.0K
> lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  3 14:56 022A4E072A4DF865 -> /proc/sys/GLOBAL??/Volume{07f378c0-0785-11e2-8b16-9d8354493d98}
> lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  3 11:12 20E819DCE819B150 ->/proc/sys/GLOBAL??/Volume{33795e42-562b-11e1-9e43-806e6f6e6963}
> lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  3 15:07 5E83-34DB ->/proc/sys/GLOBAL??/Volume{a056ffe4-c49b-11e1-9a60-e01fff2983d8}
> lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  3 14:56 78F07EF2F07EB5CA -> /proc/sys/GLOBAL??/Volume{82620ba9-ebef-11e1-b0aa-c0aa65e5609c}
> lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  2 17:41 BC28CC9C28CC56D4 ->/proc/sys/GLOBAL??/Volume{ff6beeb7-ef41-11e1-be0b-bb34ac766d9f}
> lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  2 17:42 D258228358226707 ->/proc/sys/GLOBAL??/Volume{ff6beea8-ef41-11e1-be0b-bb34ac766d9f}

Ok.  But Linux UUIDs for fixed disks are equivalent in layout to Windows
UUIDs/GUIDs.  So why not just use the GUID "as is"?

  lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  3 14:56 07f378c0-0785-11e2-8b16-9d8354493d98 -> /proc/sys/GLOBAL??/Volume{07f378c0-0785-11e2-8b16-9d8354493d98}

But here's an important question.  What exactly have you won by
adding the redirection via /dev/disk/by-uuid?  The directory does
not contain any new information which isn't already available via

> Sample fstab:
> # For a description of the file format, see the Users Guide
> # http://cygwin.com/cygwin-ug-net/using.html#mount-table
> # This is default anyway:
> # none /cygdrive cygdrive binary,posix=0,user 0 0
> /slots UUID=D258228358226707 /mnt/vtapes/slots none binary,user
> /slots UUID=BC28CC9C28CC56D4 /mnt/archive/slots none binary,user
> /slots UUID=5E83-34DB /mnt/4Gmodem/slots none binary,user

I wouldn't like to allow a change in the fstab layout which introduces
variable positions for adjacent entries.  Either just


and ignore the ability to mount subdirs of drives, or something like

This addition to fstab would already be possible if the UUID is
the same as used by Windows and the mount mechanism could do this without
having to bootstrap a /dev/disk dir.

Btw., did you know that the drive is already accessible from within
Cygwin?  Try

  $ cd '/proc/sys/GLOBAL??/Volume{07f378c0-0785-11e2-8b16-9d8354493d98}/'

(note the trailing slash which is required to access the root dir of
the drive)

This already allows an equivalent mechanism today, just using symlinks
rather than mount table entries:

  $ ln -s '/proc/sys/GLOBAL??/Volume{07f378c0-0785-11e2-8b16-9d8354493d98}/slots' /mnt/vtapes/slots
  $ cd /mnt/vtapes/slots


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

More information about the Cygwin-developers mailing list