Description of problem: The /etc/fstab processing (and documentation) explicitly note that blanks may only be coded as \040. The \x20 is not recognized as a blank. Note: I'm just assuming that the /dev/disk/by-label directory is created by udev. Note 2: The same "bug" occurs in a virtual rawhide system on the same hardware Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Mount a CD image where the label contains a blank 2. Run fstab-decode findfs LABEL='<label from /dev/disk/by-label>' 3. Actual results: findfs: unable to resolve 'LABEL=<label from /dev/disk/by-label>' Expected results: /dev/loop1 Additional info: Replacing \x20 by \040 produces the expected result
CC: Kay, Karel? any comment? :)
The fstab encoding uses \<oct> and udev uses \x<hex>. The /dev/disk/by-label is a path and LABEL=<label> is a tag. The \x<hex> not interpreted as an encoding in fstab. LABEL=this\040is\040tag /mnt/foo auto defaults /dev/disk/by-label/\x20is\x20tag /mnt/foo auto defaults The findfs expects LABEL="this is tag", it means without encoding. The encoding is unexpected here. Not a bug. Closing.
O.K., I can work around it. But I submit that it is, in a sense, a "bug" that UDEV encodes blanks in a format that makes it more difficult than necessary to copy a label from the output of a "ls -l /dev/disk/by-label" and paste it into an /etc/fstab line. Why, in fact, does UDEV encode the label string? Blanks - and other "special characters" - in there would just make it easier to use, and not, I think, have any other impact on anything. It fairly trivial to change the hex cods to the octal ones, but what's the point in having two different encodings? Perhaps the "easy" solution would be to convert the /etc/fstab format to XML so it could support all file label formats without needing to encode anything. The reliance on whitespace delimiters by fstab seems somewhat archaic.