Bug 726748

Summary:	The blanks in labels displayed in /dev/disk/by-label are coded as \x20, not \040
Product:	[Fedora] Fedora	Reporter:	Peter Trenholme <PTrenholme>
Component:	udev	Assignee:	Harald Hoyer <harald>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	15	CC:	harald, jonathan, kay, kzak
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-07-29 18:48:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Peter Trenholme 2011-07-29 17:33:55 UTC

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

Comment 1 Harald Hoyer 2011-07-29 18:04:10 UTC

CC: Kay, Karel? any comment? :)

Comment 2 Karel Zak 2011-07-29 18:48:30 UTC

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.

Comment 3 Peter Trenholme 2011-07-31 14:38:15 UTC

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.