Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Another rope-shortener: Fixing filenames

Posted Apr 3, 2009 21:24 UTC (Fri) by dwheeler (guest, #1216)
Parent article: Shortening the rope

Another example of a rope-shortener is the discussion about Fixing Unix/Linux/POSIX Filenames: Control Characters (such as Newline), Leading Dashes, and Other Problems, as discussed in last week's LWN.

(Log in to post comments)

Posted Apr 3, 2009 21:45 UTC (Fri) by ballombe (subscriber, #9523) [Link]

Actually restrincting filename is in conflict with rope shortening:

A good way to avoid rm * to remove your home directory is to do
file=$(echo -e "$HOME/\01"); touch $file; chmod 000 $file
However forbidding control characters in filenames would break that.

(Restricting filename breaks a number of programs, for example flwm and other windows managers that use filenames as menu titles.)

Another rope-shortener: Fixing filenames

Posted Apr 4, 2009 10:10 UTC (Sat) by modernjazz (guest, #4185) [Link]

> Actually restrincting filename is in conflict with rope shortening

Only if there isn't another way to solve the same problem, like putting
safeguards against deleting a home directory.

Another rope-shortener: Fixing filenames

Posted Apr 17, 2009 12:12 UTC (Fri) by Ross (subscriber, #4065) [Link]

This is a horrible idea.

First, which characters are "safe" is going to depend on context. Lots of shell scripts have trouble
with spaces in filenames. Some programs forget to escape strings used inside regular
expressions, so characters like "." and "?" would get in the way. And then there are characters
which can confuse people. Such as "S" vs. "5". Obviously we should only be using one or the
other. This is not even considering all of the variants of the same letter available in Unicode.
Let's also look at filename lengths; the only length that the majority of existing software can
handle properly is eight characters per file, 255 characters per path. Do we really want to limit
ourselves to "protect" against all these things?

Second, this is implementing policy which is in direct opposition to the previous policy: "no slash
or NUL". It would break all kinds of existing applications and scripts, break interoperability with
other systems, and generally make life more difficult.

Third, you can make conventions without enforcing policy. So don't write code which puts
hyphens and newlines in filenames. Just pick an encoding convention and stick with it (UTF-8 is
the obvious choice for Unix-type systems). Basically, take advantage of the fact that no policy is
being enforced by selecting your own.

I'm slightly surprised the proposal wasn't an April Fools joke :(