Re: native symlink

[Jeffrey Altman <jaltman at openafs dot org>]

Perhaps we would all be better off taking this discussion to main cygiwn
mailing list.  I've been reluctant to respond here because of the
request to take the discussion elsewhere but I believe that have a
unique perspective as the implementer of cross-platform (but primarily
UNIX focused) file system on Microsoft Windows.

I completely understand Christopher's inclination to treat Cygwin as a
Linux compatible black box that happens to run on Windows and not as a
layer that glues the two worlds together.  There are many contributors
to OpenAFS that take the position that the file system semantics of AFS
on Windows must be the UNIX semantics.

The downside of that approach is that it does address the needs of
organizations which have a diverse mixture of applications all of which
need to view the same file system name space because data is never
constrained to just one of the environment or framework.

For AFS this meant simulating a broad range of Windows file system
semantics which have no equivalents in AFS.  One of the areas in which
OpenAFS has been forced to adapt is in the exporting of AFS mount points
and symlinks into the Windows environment.  Ensuring compatibility with
Cygwin applications is important because just about every organization
that uses a cross-platform file system such as AFS also uses Cygwin for
its ability to provide cross-platform application support.

In fact, many of the AFS end user organizations provide Cygwin
applications to their end users by installing Cygwin once in the AFS
name space and then executing it locally on each endpoint.

I tried representing AFS Symlinks using a Microsoft assigned Reparse
Point Tag.  The downside of following that approach was that Cygwin does
not properly handle Reparse Point Tags that it does not recognize.  By
discarding the RP attribute and preserving the other reparse point stat
information (timestamps, attributes, size, etc) it introduces data
corrupting behaviors into Cygwin applications.

As Christopher knows, I started down the path of adding OpenAFS Reparse
Point support to Cygwin but unlike James I do not have the months to
dive into the path.cc labyrinth.  I also discovered that Cygwin wasn't
the only environment/framework that poorly handled non-Microsoft Reparse
Point Tags.  In fact, Explorer Shell, .NET, Pre-1.7 Java, and many home
grown applications completely botch it.  In the end I concluded the
safest thing to so was to piggyback on the Microsoft Symlink Tag.

>From the Cygwin perspective the nice thing about the change that went
into OpenAFS 1.7.22 is that Cygwin can read an AFS symlink and make use
of it with no code changes.   However, Cygwin "ln" cannot be used to
create a symlink in AFS because Cygwin doesn't write Microsoft Symlinks
and AFS cannot store the DOS SYSTEM attribute.  OpenAFS has for years
provided its own "symlink.exe" command that can be used to create
symlinks but the fact is that if Cygwin exposes AFS symlinks as Cygwin
symlinks end users are going to expect the standard UNIX processes to
create them as well.

Speaking as a representative of the OpenAFS user community, many of whom
are very large RedHat customers, adding support for creating Windows
native symlinks when it is safe to do so would have significant
benefits.  Especially for those that value a single seamless name space
accessible to all application.

At the moment Cygwin symlinks are not exposed outside the Cygwin
environment.  As such they don't generate help desk requests from
non-Cygwin applications.  As I recently discussed in my blog post, the
biggest issue with Microsoft Symlinks is the lack of support across all
applications and all file system interfaces.  Exporting Cygwin symlinks
as Microsoft Symlinks can have downsides for applications that are not
prepared to handle them.  I respect the fact that the Cygwin developers
might be reluctant to accept responsibility for furthering their use.
However, there is a very clear test that can be applied to determine
when Microsoft Symlinks should be generated in preference to Cygwin
symlinks:

  Does the Cygwin application have the
  SeCreateSymbolicLinkPrivilege privilege?

Processes will only have this privilege if the organization has granted
it to the user/group the process is running as OR if the process is
running as an elevated Administrator.

Another test that can be performed at run time is:

  Does the FileSystem Characteristics include
  FILE_SUPPORTS_REPARSE_POINTS?

Of course there are external to Cygwin methods that could be implemented
to expose Cygwin symlinks to applications.

 1. James proposes an external tool that reads a Cygwin's
    symlinks with Microsoft Symlinks.

 2. A file system filter driver could be installed on XP and
    above to capture the creation of Cygwin symlinks and replace
    them with Microsoft Symlink.

 3. A file system filter driver could be installed which
    recognizes Cygwin's (and for that matter Interix's) symlink
    files and performs the necessary file system path rewriting
    and reparsing.

There are probably additional approaches but none of them are clean and
transparent.  The second two involved significantly more complexity then
maintaining support within Cygwin's path.cc and could potentially
introduce incompatibilities with future Cygwin path.cc changes.

As I see it, as flawed as Microsoft Symlinks are they are the common
interface that enables mixed applications to communicate with one
another.  As such, where they can be used, they should be used.  What is
the point of cross-platform support if mixed platform applications
cannot transparently share the data?

Jeffrey Altman
OpenAFS Gatekeeper and Elder Emeritis