Re: You've made be rant now..
"I think your early points are great, but you lost me starting at...
"Indeed, there are many who argue that kernels should not allow files to exist which start with a '-', or contain spaces, newlines, tabs, various binary characters etc..."
My view is that if I'm the sysadmin for a multiuser system, it's *my* prerogative to prevent silly filenames creation by the users. It should *not* be a kernel default; but a filesystem mount option to reject open/creat/mknod/ link/symlink/rename operations where the target filename contains characters from \001 to \037 would be entirely appropriate and save lots of user confusion when they create such problem files by accident. This is fine for UTF-8 encoding and EUC coding."
Hiya. Sorry for the delay in replying.
I told you I was on a rant, so I'll probably backtrack a bit :-)
I agree with you (I think!)
Some argue it should be a kernel default (DWheeler in the article I linked too, for example) - but I don't. Besides, that horse has bolted already, and any new restriction would undoubtably cause problems.
But I probably didn't show that I also agree that such restrictions should be possible, and easily configurable by the sysadmin if he/she thinks it's appropriate. - Just as you describe above.
"...And if my users want to store data against arbitrary binary keys using 'special' C programs to make 'special' filenames, I'll tell them: Don't use a filename as the key, because it's a half-arsed hack. Instead, here you go, sqlite3 or gdbm or bdb, take your pick, they *do this stuff for you*. Oh, by the way, you can *even* use data containing '/' and ASCII NUL as a key. Whoa!!!!"
Backtrack time..... Yes, I agree and like to think I'd behave the same way!
The point I was trying to make was that it doesn't need to be a kernel based restriction - not that such a restriction shouldn't be possible.
But then I ranted off in some utopian way about the freedom of the programmer to be able to do what he/she wants without OS restriction that isn't necessary for the OS to work - but I didn't provide any practical real-world example.
I've never used such weird characters, and can't see any situation where I would recommend it - I was just trying to say that an arbitary restriction shouldn't be a place just to protect some programmers from writing prograns with parsing bugs, or indeed programmers silly enough to use stupid characters in the first place.
"The traditional "woo, anything goes except '/' and \0!" boast is making a virtue out of what likely started as laziness on the part of the kernel programmers. Laziness which probably made perfect sense for the times and the Bell CSRG's use cases. These days, adding an extra "check character code is greater than 32" to the kernel path parsing is not such a burden. It will branch predict correctly almost all the time."
So now it should be in the kernel? :-)
More backtracking from me... Fair enough, and you are right.. If such sane restrictions were in place from the beginning, I'd be cool with that.
TL; DR - I guess what I'm getting at is that this is how it is. It works. It can cause problems, but programmers should know this, and act accordingly. It's not something that needs to be 'fixed' at an OS level to stop the sky falling in. And ultimitely a blanket restriction would just be an added restriction that isn't actually necessary.
A lot of the power (and problems) in UNIX comes from it's rawness, and whilst any effort to make it easier and less exposed should be applauded, whilst I was in rant mode I was concerned with enforced 'dumbing down' - as it seems car analogies are usually used at thjs point, I'd say that you wouldn't force an experienced driver to drive an automatic car, just because some people can't drice manual (stick-shift) - even though in some situations said driver may even decide an automatic is his most suitable choice.
"UNIX got some things really right, but some of what the early designers chose not to care about has turned out later to cause problems for scaling and security. What made sense for the use cases and developer resources of a CS research lab in the early '70s is not necessarily appropriate now. Robust filesystems with synchronousness guarantees, race-free file syscalls and other niceties all came about because people recognised the need to take UNIX beyond what Ken and Dennis first envisaged. No slight to the inventors, just progress."
Yes. Situations have changed, and the other stuff you mention above I agree with, but whilst tightened restrictions on filenames would probably make some programs more robust, without these restrictions the filesystem itself is no less robust if the programmer knows what he/she is doing.
I think I more or less agree with you, I just didn't explain well why I thought 'unnecesaary' restrictions shouldn't be enforced in the kernel, but as you say, under the control of the sysadmin.
I hope I've explained myself more clearly, and didn't backtrack too much, but thank-you for reigning me in!
Cheers, Jamie
P.S. I've just written this using the 'w3m' console browser under an xterm session, because VI (or any other text editor) is far better for writing long replies than some slow click-and-type 'notepad-style' gui.... How I wish my current GUI browser setup allowed me to use an external editor like with the Firefox 'ItsAllText!' extension...
El Reg is one of the few sites you can actually use a non-GUI browser on these days...... The last of a dieing breed...