Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
To: cygwin AT cygwin DOT com
From: Frank-Michael Moser <moser AT decodon DOT com>
Subject:  Re: Cygwin and NTFS Junction Points
Date:  Wed, 03 Aug 2005 20:27:40 +0200
Lines: 122
Message-ID: <dcr2ap$43a$1@sea.gmane.org>
References:  <080320051737 DOT 1393 DOT 42F100EC00014F6E0000057122007358340A050E040D0C079D0A AT comcast DOT net>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1
Content-Transfer-Encoding:  7bit
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
In-Reply-To: <080320051737.1393.42F100EC00014F6E0000057122007358340A050E040D0C079D0A@comcast.net>
X-IsSubscribed: yes


> To some degree, Junction Points are more like directory HARD links,
> rather than symlinks. 

I agree. Most of the behaviour I referred to as bizarre is the behaviour
of hard-linked directories. The mentioned NTFSLink tool so mostly
emulates symlink behaviour for JPs.

> Are you offering?  cygwin.com/acronyms#PTC

Nice try ;) Unfortunately I never have programmed anything in C. But I
think it should be valid to discuss ideas like this here. Just to be
clear, I'm not complaining or requesting anything.

> I'm not about to patch the coreutils to support JPs if cygwin itself is
> not patched first.

I understand and this makes sense to me.

> Unfortunately, that will probably remain true even if cygwin behavior
> on JPs is changed, since you then have to be careful to tell cp, mv,
> and rm whether or not to dereference links during the recursive
> traversal.

This would be quite OK. Currently I use Microsoft's "linkd" commandline
tool to remove the junction before and recreate after I touch their
parent folders with Cygwin's fileutils recursively.


Thanks for your thoughts,
Frank-Michael


Eric Blake wrote:
> Ugh - top-posting.  Reformatted.
> 
> 
>>>>Since I have discovered NTFS Junction Points (NTFS 5.0+) I'm using them
>>>>frequently to symbolically link directories in a POSIX conformous way:
>>>>The junction points (JP) are transparent to *any* program using the
>>>>filesystem.
> 
> 
> To some degree, Junction Points are more like directory HARD links,
> rather than symlinks.  There are a lot of semantics to think about
> with directory hard links; POSIX allows them, but does not require
> them, and modern OS's tend not to support directory hard links
> because of the possibility of creating loops or other weird problems.
> 
> 
>>>>Unfortunately there are bizarre issues related to manipulating JPs from
>>>>the explorer or with DOS commandline tools:
>>>>
>>>>http://encyclopedia.thefreedictionary.com/NTFS%20Junction%20point
>>>>http://shell-shocked.org/article.php?id=284
>>>>
>>>>But there are tools which help to avoid these bizarre effects. E.g.
>>>>http://www.elsdoerfer.info/ntfslink/ is an explorer extensions which
>>>>hooks into Windows Explorer, providing extended functionality for
>>>>creating and using JPs on NTFS file systems.
>>>>
>>>>Now has anybody thought about respecting JPs under Cygwin? Respecting
>>>>JPs at least would mean:
>>>>
>>>>a) recursively copying JPs (or their parent folders) should not
>>>>recursively copy the content of a JP but copy the JP itself (reproducing
>>>>it at the new location, if possible)
>>>>
>>>>b) recursively removing JPs (or their parent folders) should not
>>>>recursively remove the content of a JP but remove the JP itself (leaving
>>>>the content of its target folder untouched)
>>>>
>>>>c) moving JPs (or their parent folders) should not recursively move the
>>>>content of a JP but move the JP itself (leaving the content of its
>>>>target folder untouched)
>>>>
>>>>Wouldn't this be a valid improvement to Cygwin, at least as an option?
>>>>What is your opinion?
> 
> 
> Are you offering?  cygwin.com/acronyms#PTC
> 
> 
>>>
>>>Well... doesn't find -xdev do the job sufficiently already?
>>>
>>>
>>>Corinna
>>>
>>
>>Unfortunately "find -xdev" does not work because junction points also
>>can point to target folders on the same filesystem. Also I meant that
>>using fileutils like cp, mv, and rm should transparently respect
>>junction points and handle them in like symlinks under Linux as I
>>described it in my post.
> 
> 
> cp, mv, and rm will only treat junction points insofar as the underlying
> cygwin does.  Cygwin itself would need to be patched to recognize
> junction points, and to either treat them as hard links or as symlinks.
> Cygwin currently does not deal with, or expect, directory hard links.
> I'm not about to patch the coreutils to support JPs if cygwin itself is
> not patched first.
> 
> 
>>At the moment I must pay highest attention *not* to use these tools
>>recursively on junction points or their parents to avoid bizarre
>>behaviour like unexpected vanishing of the targeted files.
> 
> 
> Unfortunately, that will probably remain true even if cygwin behavior
> on JPs is changed, since you then have to be careful to tell cp, mv,
> and rm whether or not to dereference links during the recursive
> traversal.
> 
> --
> Eric Blake
> volunteer cygwin coreutils maintainer
> 
> 
> 



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