X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=0.4 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FSL_RU_URL,RCVD_IN_DNSWL_NONE,TW_MK,TW_YG
X-Spam-Check-By:	sourceware.org
MIME-Version:	1.0
In-Reply-To:	<999310079.20101124040916@mtu-net.ru>
References:	<AANLkTik5e=pvzaqW+Rxq33NQu1AyaAq3uLmZD3Cb8s5N AT mail DOT gmail DOT com> <999310079 DOT 20101124040916 AT mtu-net DOT ru>
Date:	Wed, 24 Nov 2010 14:24:26 +1100
Message-ID:	<AANLkTik=XQP9y3uCmcr4NMva82V4bZ3x=7yFNBe4R=G6@mail.gmail.com>
Subject:	Re: cygpath unable to translate the *nix path to an NTFS junction point
From:	Pierce Morton <pierce DOT c DOT morton AT gmail DOT com>
To:	Andrey Repin <cygwin AT cygwin DOT com>
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On Wed, Nov 24, 2010 at 12:09 PM, Andrey Repin <anrdaemon AT freemail DOT ru> wrot=
e:
> Greetings, Pierce Morton!
>
> This is expected behavior for cross-links.

I took a look at the behaviour of cygpath when using cygwin symlinks
and I understand now why it does what it does with junction points.
Consistency between the two seems reasonable if that was its existing
behaviour before junction support was added.
However, the behaviour of cygpath is not entirely consistent between
junctions and symlinks.

Let's say you have the structure
c:\example\targ
c:\example\targ\subfolder
c:\example\junc
c:\example\sym
where targ and its child are real folders, junc is junction point
leading to targ, and sym is a cygwin symlink leading to targ.

cd /cygpath/c/example
cygpath -w -a junc
cygpath -w -a sym

both cygpath calls produce
c:\example\targ

The same happens with calls like
cygpath -w /cygdrive/c/example/junc
cygpath -w /cygdrive/c/example/sym

Go inside the subfolder via the junction point:
cd /cygdrive/c/example/junc/subfolder

and call cygpath again to find the absolute path:
cygpath -w -a .

and you're given:
c:\example\junc\subfolder

Try this with the symlink however:
cd /cygdrive/c/example/sym/subfolder
cygpath -w -a .

and you'll get
c:\example\targ\subfolder

One uses the dereferenced path, and one uses the symbolic path.


> However, the real reparse points mounting different volumes...
>
> [C:\]$ uname -a
> CYGWIN_NT-5.1 daemon2 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
> [C:\]$ dir C:\ | grep arc
> 2010-11-22 =A012:16 =A0 =A0<JUNCTION> =A0 =A0arc
>
> [C:\]$ cygpath -w /c/arc
> C:\arc
>
> Real junction target: \\?\Volume{4aee6480-972b-11de-b8ca-0015f2ef1bb5}\arc
>

That's interesting, but I'm not doing anything as complex as linking
across volumes.

In your case ... perhaps cygpath should attempt to match volume names
to see whether that volume has a real drive letter, then substitute
into the generated path as necessary?


>> This leaves cygpath completely unable to translate the original path
>> of an NTFS junction. =A0This is proving to be a problem for me (I'm
>> trying to use the output of cygpath for the equivalent of a backtick
>> operation in another script...)
>
>> I haven't taken a look at the C source yet, so I'm not sure whether
>> this problem lies in cygpath itself or the cygwin API layer.
>
> Say, it's a missing feature.
>
> @Corinna: Any chance cygpath get a --nofollow switch or something?

+1 for --nofollow

The reason I need this is because I need certain Windows apps to treat
the junction point in a transparent fashion, similarly to how most nix
apps treat symlinks.  I want to pass the translated path to a Windows
app so that it can work with that path without ever being aware of
when the junction point in the path changes to point to something
else.  The app needs to think C:\example\junc\importantfile.blah is
located in the same place when it could be a different file in a
different directory any day via the junction.

I also want to be able to target the junction point itself (so I can
deal with it using junction tools such as Junction from Sysinternals
or mklink etc).  Right now I can't pass the untranslated address of
the junction to anything.

This would be solved by giving cygpath the option to do a nofollow translat=
e.


Apologies if this message ends up somewhere strange - I've never
really used a old-school mailing list like this before.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -