www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Proposal for std.path replacement

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
Apr 07 2011