From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Newbigin Subject: Re: RFC: Illegal Characters in File Names Date: Thu, 22 Jul 2004 13:17:20 +1000 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <40FF31C0.1090500@it.swin.edu.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from venus.it.swin.edu.au ([136.186.5.30]:64208 "EHLO it.swin.edu.au") by vger.kernel.org with ESMTP id S264843AbUGVDRX (ORCPT ); Wed, 21 Jul 2004 23:17:23 -0400 To: linux-fsdevel@vger.kernel.org In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org Bryan Henderson wrote: ... > But really, the idea of making a terminal send a command is a red herring. > The problems of non-text filenames are more basic: > > I have personally lost a lot of time in cases where 'ls' misled me as to > the contents of my directory. (I eventually found the --almost-all and > --human-readable options of GNU Ls and have been much happier since). So your problem is that ls does not do what you want by default. The issue of 'control codes do bad things to terminals' is as you say a red herring. I see a suspect file, even if the name does not contain control codes, the file it's self might. By catting the contents I am still vulnerable for the same reason. My tools (in this case cat) don't do what I want (such as escape the control codes). In the same way, if I don't know how to use any other tool, I might be misled by incorrect output. > > I wouldn't stop at nonprinting characters. Punctuation, especially spaces > and tabs, cause a lot of trouble too, for very little gain. These all give me the shits too, but I don't use them. I try to educate other users but I don't force them not use use them. Particularly windows users using samba like to use spaces. > > As I've said, I don't want to take away your weird filenames. But I'd > like to get rid of mine. I'd rather have an untar fail than create a > filename that's going to cause me grief. Exactly. You should have control over your environment. A per user filename filter could do this. You can turn it on and off, configure special encodings whatever. If all your filenames turn to shit, the system still works and you don't impact other users. If you don't like the files other people leave in /tmp then use a private /tmp. (Why don't we have a vfs which can make my private tmp appear on /tmp?) Preventing these characters at the filesystem is not good because it impacts on people who want (perhaps misguidedly) to use them. > > > In one of my earliest encounters with a computer, someone distributed a > program that created a status file with a command line editing character > in its name. He did it to try to stop people from deleting it -- it was > impossible to delete it with a typed command. He didn't think through > just what effect attempting to type such a command would have. What it > did was create a command that says, "delete the file I most recently > worked on." I deleted 3 important files before I realized what was going > on. We know that all valid filename characters can be entered into a bash shell if correctly formatted & escaped. There are no impossible to delete file names (except for perhaps, impossible to create file names, which fsck should fix). If people write software that does silly things then that software needs to be fixed. Your own admission is that the author did not think about what they were doing. The unix fs is a bit like C++. You can do heaps of stupid things (c++ multiple inheritance, operator overloading) but you probably shouldn't. Just because you don't however, does not mean that you should remove them from the language.