This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygpath unable to translate the *nix path to an NTFS junction point


On Wed, Nov 24, 2010 at 12:09 PM, Andrey Repin <anrdaemon@freemail.ru> wrote:
> 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 ?12:16 ? ?<JUNCTION> ? ?arc
>
> [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. ?This 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 translate.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]