digitalmars.D - Re: Proposal for std.path replacement
- "Jonathan M Davis" <jmdavisProg gmx.com> Apr 07 2011
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