Date: Tue, 17 Aug 2010 20:49:31 +0200 From: walter@pelissero.de (Walter C. Pelissero) To: Oliver Fromme <olli@lurza.secnetix.de> Cc: freebsd-bugs@FreeBSD.ORG, bug-followup@FreeBSD.ORG Subject: Re: bin/149424: fstab and labels with whitespace Message-ID: <19562.55739.75948.533618@zaphod.home.lan> In-Reply-To: <201008171506.o7HF6QL7075437@lurza.secnetix.de> References: <19562.39686.747733.126631@zaphod.home.lan> <201008171506.o7HF6QL7075437@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 feature). > 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- error. 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 http://www.pelissero.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19562.55739.75948.533618>