This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFE: mount support for device UUID's


On 10/10/2012, at 9:20 PM, Corinna Vinschen wrote:

> On Oct 10 17:42, Mark O'Keefe wrote:
>> Hi Corinna,
>> On 09/10/2012, at 7:53 PM, Corinna Vinschen wrote:
>> 
>>> 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 :-}
>> 
>> Sorry about that.  Unfortunately my mail program doesn't support this
>> so I had to eyeball where 80 characters was - obviously poorly :-)
> 
> Thanks.
> 
>>>> [...]
>>>> 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...
>> 
>> Agreed.  It would certainly be nice to have this populated based on
>> what is connected, however that introduces the dependency on
>> libblkid.
> 
> 
> 
>> I'm not sure this is acceptable inside the core of
>> cygwin.
> 
> No, it isn't.  The Cygwin DLL may only rely on OS-provided functionality.
> 
>> Alternative would be to extract (copy) the related code
>> over to cygwin (not sure how viable that is and it introduces
>> maintenance implications).
> 
> Licensing may be an issue.  Let me see... yes, it is.  LGPL is not
> feasible for inclusion into Cygwin.
> 
>> It would also be necessary to look
>> at how to get the best performance out of this (caching and
>> recognising when drives connect/disconnect).  I didn't know enough
>> about the internals of cygwin to determine how feasible this was.
>> If the connect/disconnect of a drive could trigger the necessary
>> drive read to get the UUID and populate this as a virtual directory
>> then that would be a better solution that is resilient to change.
>> 
>>> 
>>>> 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"?
>> 
>> 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.
> 
>>> 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
>>> /proc/sys/GLOBAL??.
>> 
>> Actually it does.  As stated above, the UUID/GUID of Windows does
>> not match the UUID extracted from blkid.  If you run blkid on the
>> disk you get the correct value.  This value is the same as the
>> value returned if you then connect that disk to a linux based
>> system.  This value doesn't change without physical change to
>> that disk partitioning, unlike the UUID/GUID of Windows.
> 
> I'm not sure about the latter.  If the volume manager would change the
> GUIDs on the fly, it would be contrary to its job.  Either way, in all
> cases, Windows/Linux/etc, there's a chance to change the GUIDs.
> Reformatting or repartitioning of a drive, setting the UUID explicitely,
> whatever.  In all cases this requires a deliberate action on the user's
> account.  This is no good reason to disregard the method which is already
> available.
> 
>>> I wouldn't like to allow a change in the fstab layout which introduces
>>> variable positions for adjacent entries.  Either just
>>> 
>>> UUID=07f378c0-0785-11e2-8b16-9d8354493d98
>>> 
>>> and ignore the ability to mount subdirs of drives, or something like
>>> UUID=07f378c0-0785-11e2-8b16-9d8354493d98/slots
>>> 
>> I like this option over the previous.  What I noticed was that if
>> you did the first, then it overrides the cygdrive mount point.
> 
> It shouldn't, unless there's a bug in the code.
> 
>> I think the second option allows for the first as a variant anyway.
>> It is more flexible.
> 
> Right.
> 
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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]