• "Jonathan M Davis" <jmdavisProg gmx.com> Apr 07 2011

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

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