Theodore Tso wrote, on 2009-07-26 09:20:
On Sat, Jul 25, 2009 at 05:42:01PM +0200, Marco d'Itri wrote:
Thank you for your testing. It make me suspect that the file name do
not really contain space, but the string '\x20' instead. This is then
interpreted differently by different programs. fsck understand it to
mean 'x20', while mount understand it to mean '\x20'. Neither seem to
understand it to mean ' ' (space).
udev outputs a string which is supposed to be used literally, I do not
know why fsck tries to \-expand paths in fstab.
So far it's the only program which stands out by not understanding the
name, if the maintainer disagrees than I fear that this will have to be
sorted out between him and the upstream udev maintainer since I am not
going to modify the persistent names just for Debian.
What works consistently across both fsck and mount, and what I would
recommend you use instead, is something like this:
LABEL=W-98\040SE /mnt vfat defaults 0 0
This works just fine for both mount and fsck.
The LABEL= and UUID= is much more reliable than /dev/disk/by-label and
/dev/disk/by-uuid. For example, for a newly created filesystem,
/dev/disk/by-uuid and /dev/disk/by-label don't get updated until you
reboot the system, which is very.... Windows-like.
LABEL= and UUID= will reliably work as soon as you create the new
filesystem. /dev/disk/by-label and /dev/disk/by-uuid are broken by
design. This is why blkid has been merged into util-linux-ng, and
used by default --- because it works reliably, whereas the udev
pathnames do not. Note that fsck will also be shortly transfering to
util-linux-ng, but until then sure, I'll investigate making sure that
mount and fsck are consistent in terms of how backslashes are handled.
Note that backslash support is needed in order to support actually
having real spaces in pathnames, although the main reason why it was
added was so that things like "LABEL=W-98\040SE" would work
consistently accross fsck and mount --- which it does; I just tested
it.
- Ted
Thanks, I've converted my /etc/fstab to use LABEL=W-98\040SE for the
above case (and UUID=0831-11DD UUID=11F1-3E5D UUID=4823-93A9 for a
couple of real SCSI filesystems and a USB drive) and they all mount
fine. I did confirm that they fsck on boot-up alright.
For the Debian bug to be closed, perhaps the manual page for fstab(5)
should be changed from:
[quote]
Instead of giving the device explicitly, one may indicate the (ext2 or
xfs) filesystem that is to be mounted by its UUID or volume
label (cf.
e2label(8) or xfs_admin(8)), writing LABEL=<label> or
UUID=<uuid>,
e.g., `LABEL=Boot' or
`UUID=3e6be9de-8139-11d1-9106-a43f08d823a6'.
This will make the system more robust: adding or removing a
SCSI disk
changes the disk device name but not the filesystem volume label.
[end quote]
to indicate that ext3/ext4 and vfat are supported:
e2label (8) - Change the label on an ext2/ext3/ext4 filesystem
I noticed that dosfslabel did *not* find the label for the device that
was able to be mounted by LABEL=W-98\040SE
Thanks again and regards,
Arthur.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
