This is the mail archive of the cygwin-developers 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: support for writing reparse-point symlinks


On 12/8/12 7:28 PM, James Gregurich wrote:
> Around the beginning of this year, I took it upon myself to modify
> cygwin's dll so that when one invokes the posix symlink() function it
> will attempt to use a reparse-point rather than the usual cygwin
> symlink file. 

By reparse point, you mean a Windows symbolic link, right? (The
Windows symbolic link is one kind of reparse point.)

> I have employed a strategy for handling reparse points
> in cygwin that works well in practical use. We use this modified
> version of cygwin to host our git repositories on Windows.

Why did you do this work? Were you trying to increase performance or
improve interoperability? If the former, do you have before and after
performance numbers?

> I have seen in past emails on this list that there was no interest
> in implementing support for creating reparse points in cygwin because
> there were questions about the practical usability. Our experience has
> been that it works fine for us over the last year. I'd like to raise
> the question for reconsideration by the cygwin developers. I'd be
> willing to contribute my and design and code to the project as I would
> prefer not to maintain our own custom version of cygwin forever.

As I understand it, there are four major issues that prevent Cygwin
using Windows symbolic links for its own symlinks:

1) Windows symbolic links are "directory" or "file" symbolic links,
depending on the type of the target, but POSIX has only one kind of
symbolic link.

2) Windows symbolic links point to Windows paths, but Cygwin symbolic
links point to POSIX paths. If the Cygwin mapping table changes,
Windows symbolic links will begin pointing to the wrong place.

3) By default, only administrators can create Windows symbolic links.

4) Cygwin still supports Windows XP, and Windows XP does not support
symbolic links.

Cygwin symbolic links work well enough, and I don't think trying to
overcome these difficulties is a high priority.

That said, someone brought up a few months ago the possibility of
using a _custom_ reparse point type, paired with a filesystem
minifilter driver, to store Cygwin symbolic links. The filesystem
minifilter driver would allow normal Windows programs to work with
these links. This discussion didn't go anywhere.

What problem are you really trying to solve here?

Attachment: signature.asc
Description: OpenPGP digital signature


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