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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
