On 2011-04-07 04:38, Lars T. Kyllingstad wrote: > On Thu, 07 Apr 2011 03:57:18 -0700, Jonathan M Davis wrote: > > And on some file systems, even / is valid! Though it's not worth it to > > try and get std.path to work with files with / in the name. It's > > generally a very bad idea to create a file with a / in the name - too > > many programs would choke on it or just plain have the wrong behavior. > > However, there _are_ *nix file systems which allow for / in file names. > > Which filesystems are those? The POSIX:2008 specification specifically > states that > > "The characters composing the name may be selected from > the set of all character values excluding the <slash> > character and the null byte." > > where <slash> is defined as '/'. > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html
I didn't know that Posix had anything to say on the matter (though it doesn't hurt my feelings any that it effectively says that / isn't valid in file names). However, the file systems themselves apparently don't necessarily stick to that. If you take a look at http://en.wikipedia.org/wiki/Comparison_of_file_systems you can see which file systems allow which characters. For instance, the exts disallow NUL and /. However ReiserFS, Btrfs, JFS, and XFS allow /. In fact, most of the Linux file systems seem to allow / (though the exts are probably the most used and they don't). Still, Posix or no, I would expect that using / in a file name would be just asking for trouble and find no reason to support it in std.path (particularly when we'd rely on the underlying C calls handling it appropriately, and I expect that there's a good chance that they don't). But if Posix disallows it, then we definitely shouldn't. Still, the file systems themselves aren't necessarily Posix-related, and apparently quite a few of the *nix file systems allow /. - Jonathan M Davis
