Proposal for std.path replacement

[Jonathan M Davis]

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