bin/149424: fstab and labels with whitespace
olli at lurza.secnetix.de
Tue Aug 17 15:10:05 UTC 2010
The following reply was made to PR conf/149424; it has been noted by GNATS.
From: Oliver Fromme <olli at lurza.secnetix.de>
To: walter at pelissero.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 17:06:26 +0200 (CEST)
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'?
In fact I *do* sometimes use backslashes in file names when
I would ordinarily use a forward slash, but of course forward
slashes are not allowed in file names.
> > Of course, it would be possible to change the syntax in a
> > backwards-compatible way. But this would require more code
> > and would potentially introduce more complications.
> Maybe you should leave alone the generic considerations of
> circumstance and write some code yourself.
> In the past 8 years there have been three different proposals and
> concrete implementations. You could add your own. So we would at
> least know what you mean with "backwards-compatible way".
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.
> > > > 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, because "not being able
to insert an entry altogether" is untrue, given the fact that
Breaking existing configurations (possibly leaving people
with unbootable remote machines!) is certainly worse than
requiring some people to use workarounds for an optional
feature. Of course, the case would be completely different
if you weren't able to mount those file systems at all.
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". Those are
just three things from the top of my head; there are probably
more. Not to mention any third-party software that might try
to parse that file.
If you want to change the syntax of /etc/fstab, *all* of the
above needs to be adapted.
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when was the
last time you needed one?"
-- Tom Cargil, C++ Journal
More information about the freebsd-bugs