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: Cygwin and NTFS Junction Points


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/


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