On 5/10/07, Karel Zak <kzak@xxxxxxxxxx> wrote:
On Thu, May 10, 2007 at 12:06:27PM +0200, Matthias Koenig wrote:
> There *are* of course issues with volume_id, which needs to be discussed:
> 1. udev creates label symlinks by default in /dev/disk/by-label/
> However the name of these links are not the label itself, but a safe label,
> which is derived by the rules:
> - '/' are skipped
> - multiple spaces are converted to a underscore '_'
> This will lead to problems when we have two volumes with label, e.g. say:
> foobar and
> foo/bar
> I think this is a point where blkid is smarter in detecting the ambiguity.
>
> 2. Device-by-label lookup is done by following the symlink in
> /dev/disk/by-label
> You will have to know the safe label, not the real label.
> When we want to do a label-by-device lookup, volume_id only provides
> the label (not the safe label). AFAIK volume_id does not export the
> way it derives the safe label. But this is important when we want to compare
Well, you can export the replace_untrusted_chars() function, but this
is not solution, because
replace_untrusted_chars("fooXbar") == replace_untrusted_chars("foo_bar)
if the 'X' is a unsafe character.
The concept is wrong, because you can't convert a "safe label" back
to the "raw label". The correct solution is escape (hex, oct, ...)
unsafe chars rather than remove it. So... /dev/disk/by-raw-label.
Kay?
Right, that sounds much nicer to encode it.
The reason nobody cared so far is that LABEL= and UUID= are just two
of many possible ways to identify a device. Udev also provides other
kind of links that identify devices persistently, based on properties
like physical path, hardware serial numbers, non-filesystem uuids,
raid-set id's, ... Label and uuid are by far not sufficient today, to
identify block devices. We just consistently use the links in
/dev/disk/ for fstab or system-management. So all the methods: by-id/,
by-path/, by-label/, or by-uuid/ use the same interface.
Thanks,
Kay
-
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
