std.path review: update

[Lars T. Kyllingstad]

On Tue, 19 Jul 2011 15:55:29 -0400, Nick Sabalausky wrote:

> "Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message
> news:j01trl$2ia$6 at digitalmars.com...
>> On Mon, 18 Jul 2011 13:16:29 -0400, Steven Schveighoffer wrote:
>>> In driveName:
>>>
>>> Should std.path handle uunc paths?  i.e. \\servername\share\path  (I
>>> think if it does, it should specify \\servername\share as the drive)
>>
>> Yes, std.path is supposed to support UNC paths.  For instance, the
>> following works now:
>>
>>  assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo`, "bar",
>>  "baz"]));
>>
>> I guess you would rather have that
>>
>>  assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo\bar`, "baz"]));
>>
>> then?  I am not very familiar with Windows network shares; is \\foo
>> never a valid path on its own?
>>
>>
> I don't know whether or not it's "never" a valid path, but "dir
> \\server" always fails and "dir \\server\share" always works (assuming
> it exists, at least). So treating the whole thing as a drive might be
> the right thing to do. (Of course, it's completely moronic that WIndows
> works that way...)
> 
> 
>>> fcmp:
>>> "On Windows, fcmp is an alias for std.string.icmp, which yields a case
>>> insensitive comparison. On POSIX, it is an alias for
>>> std.algorithm.cmp, i.e. a case sensitive comparison."
>>>
>>> What about comparing c:/foo with c:\foo?  This isn't going to be equal
>>> with icmp.
>>
>> I am a bit unsure what to do about the comparison functions (fcmp,
>> pathCharMatch and globMatch).  Aside from the issue with directory
>> separators it is, as was pointed out by someone else, entirely possible
>> to mount case-sensitive file systems on Windows and case-insensitive
>> file systems on POSIX.  (The latter is not uncommon on OSX, I believe.)
>>  I am open to suggestions.
>>
>>
> If such mountings are possible, it would seem that there must be some
> way to check the sensitivity (otherwise the OS itself would probably
> crap out on it).

That check would probably be orders of magnitude more expensive than a 
simple string operation.


> Although, at least in the case of case-insensitive mountings on posix,
> doesn't that mean such paths would have both case-sensitive and
> case-insensitive parts?
> 
> Ex: /mount/damnWinDrive/dir/subdir
> 
> Wouldn't the "mount/damnWinDrive" part be case-sensitive and the
> "dir/subdir" part be insensitve?

Argh.


> (I'm starting to really despise case-insensitive filesystems.)

Me too.

Does anyone know whether Windows' case insensitivity is limited to ASCII? 
If not, is the filesystem Unicode-aware, or does it uses some locale 
specific codepage to compare file names?

-Lars