Email for std.path submissions

[Todor Totev]

About Windows NT based systems:
First, most parts of Windows accepts '/' as valid separator in file names.
Also, the following paths are totally valid and accepted, and most of them  
will
confuse the posted code:

c:\\server\share\name - don't ask - it's a hack from Win3 era still  
living...
\??\c:\folder\file - seen in registry, it is used by native functions
\\?\c:\folder\filename - allows up to 37000 UNICODE characters in a name.
If the path is in this format it cannot be relative, cannot contain '.' nor
'..' nor '/'.
\??\UNC\Server\Share - same as above but for UNC filenames

The named streams syntax use ':', so 'filename:streamname"
must be interpreted as file with name 'filename' containing one unnamed  
stream
and one named stream called 'streamname'.
Current code will accept 'filename' as drive name if I read it correctly.
If I remember correctly, Ares have a code dealing with parts of file name  
but
I do not remeber whether it "knows" about named file streams - these will  
be
interesting test cases for that code <hint> <hint> ;-)
Regards,
Todor

P.S. The following names are also valid but they are variations of the
examples above:

\\?\Volume{d208a5aa-7554-11d9-a0af-806d6172696f}\boot.ini

is a "complete" file name in the sence it describes the full path to
the file and adding something like 'c:' will render it inusable.

And last, paths like \\.\PhysicalDrive2 are also valid.

Hope you enjoy the nice subtleness of everyone's favourite OS ;-)
Please note that everyone of the paths posted are accepted by notepad.exe
and the command interpreter cmd.exe on my machine with installed XP.
Todor


On Fri, 24 Feb 2006 18:09:58 +0200, Miles <_______ at _______.____> wrote:

> bobef wrote:
>> Never thought of that.
>> And I think it is also not correct to replace \ with / in the Linux
>> paths... I don't have enough Linux knowledge to solve these yet.
>
> Yes, it is not correct.
>
> Every character except for '/' and '\0' is a valid character for Linux
> filenames. It is even possible to embed some ANSI escape sequences on
> filenames to make them shine on different colors on ls (this is stupid
> and useless, but possible).
>
> On a side note, expandTilde() is a bit off as part of the D library...
> the meaning we give to '~' on Linux is just as a _shell feature_, and
> just a convention. Otherwise, '~' is also valid as part of a filename.