From: Erik Faye-Lund Date: Mon, 25 Jan 2010 19:45:48 GMT Subject: Re: [PATCH] Handle UNC paths everywhere Message-ID: <40aa078e1001251145o13545328o7d46086ff09e6d33@mail.gmail.com> In-Reply-To: On Mon, Jan 25, 2010 at 7:19 PM, Johannes Schindelin wrote: > Hi, > > On Mon, 25 Jan 2010, Erik Faye-Lund wrote: > >> On Mon, Jan 25, 2010 at 6:34 PM, Johannes Schindelin >> wrote: >> > Hi, >> > >> > On Mon, 25 Jan 2010, Robin Rosenberg wrote: >> > >> >> >From 37a74ccd395d91e5662665ca49d7f4ec49811de0 Mon Sep 17 00:00:00 2001 >> >> From: Robin Rosenberg >> >> 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