On Wed, 20 Jul 2011 13:36:51 -0400, Lars T. Kyllingstad
<[email protected]> wrote:
On Mon, 18 Jul 2011 14:51:06 -0400, Steven Schveighoffer wrote:
On Mon, 18 Jul 2011 14:25:57 -0400, Lars T. Kyllingstad
<[email protected]> wrote:
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?
It is and it isn't.
Well, that certainly cleared things up. ;)
It is in that if you open explorer and type in \\servername, it will give
you a list of shares you can try. But I don't think it's a valid *path*,
except in explorer. So my intuition is to declare it never a valid path.
I'm not sure how \\server interacts with the low level functions of
Windows (such as CreateFile). Some research/experimentation is probably
warranted.
It's *not* a normal directory, because only shares
can be in that directory. In other words, the point at which a UNC path
turns into normal directory structure is after the share name.
An easy way to compare is, you can only map drive letters to shares, not
to servers.
Then driveName() should probably return the full share path. But, of the
following asserts, which should pass?
assert (pathSplitter(`\\foo\bar\baz`).front == `\\foo\bar`);
assert (pathSplitter(`\\foo\bar\baz`).front == `\\foo`);
assert (baseName(`\\foo\bar`) == `\\foo\bar`);
assert (baseName(`\\foo\bar`) == "bar");
assert (dirName(`\\foo\bar`) == `\\foo\bar`);
assert (dirName(`\\foo\bar`) == `\\foo`);
Note that if you replace `\\foo\bar` with `c:\` in the above, the first
assert in each pair will pass. Same with "/" on POSIX. Basically, that
choice corresponds to treating `\\foo\bar` as a filesystem root.
Yes, I think this sounds right (pending research/experimentation cited
above).
As I understand it, some POSIX systems also mount network drives using
similar paths. Does anyone know whether "//foo" is a valid path on
these systems, or does it have to bee "//foo/bar"?
Typically, linux uses URL's, i.e. smb://server/share URL parsing is
probably not in std.path's charter.
However, I have used a command like:
mount -t cifs //server/share /mnt/serverfiles
But this is only in very special contexts. In general I don't think
//foo should be considered a server path on Posix systems.
I actually got a request on the Phobos list that std.path should support
such paths. Furthermore, the POSIX stardard explicitly mentions "//"
paths (though it basically says it is implementation-defined whether to
bother dealing with them).
ls //root lists the contents of /root. I'd guess that opening //root with
open() would simply open /root. Given that context, they should not be
considered to be a server path IMO.
joinPath:
Does this normalize the paths? For example:
joinPath("/home/steves", "../lars") => /home/steves/../lars or
/home/lars ?
If so, the docs should reflect that. If not, maybe it should :) If
it doesn't, at least the docs should state that it doesn't.
No, it doesn't, and I don't think it should. It is better to let the
user choose whether they want the overhead of normalization by calling
normalize() explicitly. I will specify this in the docs.
In fact, if you do not normalize during the join, it's *more* overhead
to normalize afterwards. If normalization is done while joining, then
you only build one string. There's no need to build a non-normalized
string, then build a normalized string based on that.
Plus the data is only iterated once.
I think it's at least worth an option, but I'm not going to hold back my
vote based on this :)
If it doesn't turn out to be a huge undertaking, I think I'll replace
joinPath() with a function buildPath() that takes an input range of path
segments and joins them together, with optional normalization. Then,
normalize(path) can be implemented as:
buildPath(pathSplitter(path));
Does that sound sensible?
That sounds good.
-Steve
