bin/149424: fstab and labels with whitespace
Walter C. Pelissero
walter at pelissero.de
Tue Aug 17 19:00:16 UTC 2010
The following reply was made to PR conf/149424; it has been noted by GNATS.
From: walter at pelissero.de (Walter C. Pelissero)
To: Oliver Fromme <olli at lurza.secnetix.de>
Cc: freebsd-bugs at FreeBSD.ORG, bug-followup at FreeBSD.ORG
Subject: Re: bin/149424: fstab and labels with whitespace
Date: Tue, 17 Aug 2010 20:49:31 +0200
Oliver Fromme writes:
> Walter C. Pelissero wrote:
> > Oliver Fromme writes:
> > > Sure, but still everyone who uses backslashes will have to
> > > change his /etc/fstab *in advance*, or otherwise his box
> > > will not boot after the update.
> > It seems to be unlikely there are systems out there relying on a
> > boot-time mounted filesystem whose device path (or label) contains a
> > backslash. Certainly not a great deal of those.
> > Maybe you care to give us some concrete example. Who knows, there
> > could be a BSD distribution, that I failed to notice, with a really
> > bizarre naming convention for the device drivers.
> What prevents you from labelling a disk 'backup\500GB'?
Besides some remorse about the uninspired name, nothing keeps you from
that. Are you also going to boot from that volume? Because that is
what you were arguing just before. So, if you aren't, your argument
about rendering systems unbootable is moot.
BTW, that was the meaning of:
It seems to be unlikely there are systems out there relying on a
boot-time mounted filesystem whose device path (or label) contains a
backslash. Certainly not a great deal of those."
> In the past 16 years (maybe longer; I checked only the FreeBSD
> repository) nobody dared to change the syntax of /etc/fstab. I'm
> not going to open this can of worms.
Are you the person responsible for that code?
> > > > > in /etc/fstab, for whatever reason. This change would
> > > > > make them rather unhappy, I'm afraid.
> > > >
> > > > Being unhappy for having to change a couple of entries in fstab is not
> > > > nearly as bad as not being able to insert an entry altogether.
> > >
> > > As I wrote, there are several workarounds.
> > Then, why do you write it again?
> Because it seemed that you missed it,
> Breaking existing configurations (possibly leaving people
> with unbootable remote machines!)
Right: machines that boot from backup\500GB, aren't they?
> is certainly worse than requiring some people to use workarounds
> for an optional feature.
Booting from backup\500GB sounds pretty "optional feature" to me.
> And finally, the patch presented in this PR fails to update all
> places that handle /etc/fstab. For example, it breaks
> /etc/rc.d/gbde, /etc/rc.d/jail and "mount -p".
Neither /etc/rc.d/gbde nor /etc/rc.d/jail is broken by my patch. (As
far as I can tell, there is not even use for the device name in
/etc/rc.d/jail.) It would, on the other hand, interfere with your ill
named USB disk if that were encrypted with GBDE (a still experimental
> Those are just three things from the top of my head; there are
> probably more.
There must be aplenty, if in 8 years nobody hasn't been able to even
> Not to mention any third-party software that might try to parse
> that file.
Parsing is not hindered by my patch. Programs that use libc to read
fstab don't have problems. Those that use some home brewed parser are
still able to parse fstab without problems, because the syntax is
backward compatible. They simply don't get the right value for those
device entries that employ backslashes.
In other words, you are in trouble if you intend to use
some\funny\device in your third-party software that doesn't use libc
to parse fstab.
> If you want to change the syntax of /etc/fstab, *all* of the above
> needs to be adapted.
That patch changes libc. Where else more central or appropriate did
you have in mind?
/sbin/mount, for -p to work, would require an equally trivial patch.
So would some other program, I suppose. Hardly a tin of
invertebrates, and nothing that cannot be discovered by trial-and-
If you meant to say: "either you mend all FreeBSD boot chain or your
patch is not enough"; well, I'm still waiting to see your code.
Or the others of your "several" workarounds.
I've seen one this far.
(Yes, I didn't miss it.)
More information about the freebsd-bugs