bin/149424: fstab and labels with whitespace

Walter C. Pelissero walter at
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 (Walter C. Pelissero)
To: Oliver Fromme <olli at>
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,
 Did I?
  > 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
 enumerate them.
  > 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.)
 walter pelissero

More information about the freebsd-bugs mailing list