Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4E31CF91.1060000@rowe-clan.net>
Date: Thu, 28 Jul 2011 14:07:29 -0700
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Bert Huijben <bert@qqmail.nl>
CC: 'APR Developer List' <dev@apr.apache.org>
Subject: Re: Researched and adapted pre-vista/2008 windows symlinks
References: <4E3187D8.5070308@rowe-clan.net>
 <05fc01cc4d5b$b87352b0$2959f810$@qqmail.nl>
In-Reply-To: <05fc01cc4d5b$b87352b0$2959f810$@qqmail.nl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 7/28/2011 12:22 PM, Bert Huijben wrote:
> 
> 
> I don't think we should implement 'fake symlinks' for Windows as suggested here (and a few times on the Subversion list). That deliberately introduce a compatibility problem with the real symlinks that are supported on Windows Vista and later. And because we use an alternative symlink, we would have to maintain the not-real-thing forever and can't start supporting the real thing. And normal Windows applications would do everything in a different way.
> 
> Junctions are the Windows equivalent of the unix 'mount' and we don't support mount on unix either.

No.  Mount reparse points are the equivalent of the unix mount.

Junctions are another entity (related to but not equivalent to mount),
and the fact that they are both reparse points is irrelevant.  So are
true ntfs symlinks, yet another two flavors of reparse points (different
between file and directory).  I don't suspect there is a good unix analog
to junctions other than "absolute directory symlinks".  (Relative junctions
are not possible).

> I don't understand why on a standard Windows a normal user can mount directories as junctions, while a normal user can't use symlinks but that shouldn't make us introduce apr-symlinks that are incompatible with Windows-symlinks.

Define incompatible, please?

To be 100% clear; on Windows 2008 with sufficient permissions, a true
symlinkd would be detected, would be created if asked.  The symlink
code would be a workaround to permissions issues and to older versions
of windows - wherever we can apr would create a true dir symlink.
Likewise for files, true file symlinks unless prevented by permissions
or by the operating system.

[You could legitimately argue that we should not fall back for permissions
but only for the version of windows in use, and I could buy that.]

> E.g. how are you supposed to mix usage of a directory with applications that can handle real symlinks?

On 2008 such applications must already recognize junctions and symlinks.
It might even distinguish between them (e.g., cmd.exe 'dir' command).
But it must be aware that they accomplish the same thing.

apr apps don't need to worry about these details, apr is here to abstract
away such details.

File hardlinks are another matter, but given that 2003 apps can't handle
symlinks at all, this poses an opportunity to offer -something-, which is
sometimes better than nothing.

> Using junctions as symlinks is only nice if you just use one application/environment.
> 
> Apr is a platform abstraction layer, used for real world applications that integrate with the OS. 
> Solutions like the faked symlinks belong in libraries like cygwin that try to create a sub-operating system, incompatible with the host system.

Ok, again to be 100% clear, .lnk is crap and I didn't suggest it.

Faux-junction directory softlinks are truly softlinks already, they differ
from an ntfs softlink in that they can only resolve to an absolute path,
and won't track if the junction and target are moved together, which is
unfortunate but shouldn't be a showstopper.

(Tracked) faux-hardlink as softlink for windows where no alternative exists
is not a false implementation, but it does differ from a true softlink.  All
windows applications would resolve the file.  Not all would recognize it as
a softlink or even as a link.  It differs from a unix softlink in that the
original file could be relocated/deleted and the link would still resolve.
Reporting them as symlinks should be relatively efficient (as >1 inodes would
be true before spin cycles deciding if this is the canonical path).

As both provide sufficient abstraction of this general case (pointing to
another file on the same file system), I'm inclined to support them for
the exact reason you responded, providing real world applications the
ability to ignore platform distinctions.

The sad part is that 2003 isn't going away any time soon, so the something
rather than nothing seems appropriate here.