Re: [PATCH] Handle UNC paths everywhere

[Erik Faye-Lund <kusmabite@googlemail.com>]

On Mon, Jan 25, 2010 at 7:19 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 25 Jan 2010, Erik Faye-Lund wrote:
>
>> On Mon, Jan 25, 2010 at 6:34 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > Hi,
>> >
>> > On Mon, 25 Jan 2010, Robin Rosenberg wrote:
>> >
>> >> >From 37a74ccd395d91e5662665ca49d7f4ec49811de0 Mon Sep 17 00:00:00 2001
>> >> From: Robin Rosenberg <robin.rosenberg@dewire.com>
>> >> Date: Mon, 25 Jan 2010 01:41:03 +0100
>> >> Subject: [PATCH] Handle UNC paths everywhere
>> >>
>> >> In Windows paths beginning with // are knows as UNC paths. They are
>> >> absolute paths, usually referring to a shared resource on a server.
>> >
>> > And even a simple "cd" with them does not work.
>> >
>>
>> But it does, at least for me - both in bash and cmd.exe. I just need
>> to log on to the server first, unless it's a public share.
>
> I love it when people say "it works for me, so let's do it".
>
> _My_ _only_ instance of Windows cmd says this:
>
>        C:\Blah> cd \\localhost
>        '\\localhost'
>        CMD does not support UNC paths as current directories.
>
>        C:\Blah>
>
> So.

Actually, you're right about cmd.exe - I somehow mixed that up.
However, it works fine in bash (and simply by doing chdir() from a
normal C-program), as long as I've logged on in advance.

This applies to my Vista 64 and XP installations.

>
> Besides, the patch was not in a form where I can say that it was obviously
> fixing the issue. It was rather in a form where I would have to have set
> aside a substantial amount of time to verify that nothing undesired was
> introduced as a side effect.
>

This I can agree on. I just wanted to clear up the situation about
cd'ing. But I failed - hopefully that's corrected now.


-- 
Erik "kusma" Faye-Lund