You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2011/07/28 18:01:28 UTC
Researched and adapted pre-vista/2008 windows symlinks
http://fearthecowboy.com/2011/04/04/coapp-package-composition/
http://fearthecowboy.com/2011/04/07/simulating-symlinks-for-windows-xp2003/
For Windows 2003 directory-junction-symlinks and faux-file-symlinks;
https://github.com/coapp/toolkit/blob/master/Win32/ReparsePoint.cs
https://github.com/coapp/toolkit/blob/master/Win32/LegacySymlink.cs
and the applicable license;
https://github.com/coapp/toolkit/blob/master/License.txt
We shouldn't be supporting 2000 and prior anymore... these would not
work on FAT32 filesystems, but I believe NTFS has been the default
for some time now (and FAT isn't an acceptable server filesystem).
So just asking, should we adopt this, before I start to work on it?
Re: Researched and adapted pre-vista/2008 windows symlinks
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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.
Re: Researched and adapted pre-vista/2008 windows symlinks
Posted by "William A. Rowe Jr." <wr...@apache.org>.
On 7/28/2011 1:15 PM, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Mladen Turk [mailto:mturk@apache.org]
>> Sent: donderdag 28 juli 2011 22:07
>> To: Bert Huijben
>> Subject: Re: Researched and adapted pre-vista/2008 windows symlinks
>>
>> On 07/28/2011 09:22 PM, Bert Huijben wrote:
>>>
>>>>
>>>> So just asking, should we adopt this, before I start to work on it?
>>>
>>
>> Attached a working solution :)
>> The APR-zing should be quite simple
>>
>>
>>> 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.
>>>
>>
>> FYI on Vista+ symlinks *are* Junction points. Their limit is still 32 per dir.
>> It just happens Microsoft created an nice API for making them.
>
> F:\tst>dir
> Volume in drive F is Projects
> Volume Serial Number is 8817-32E5
>
> Directory of F:\tst
>
> 28-07-2011 22:12 <DIR> .
> 28-07-2011 22:12 <DIR> ..
> 28-07-2011 22:10 <SYMLINKD> dirlink [subdir]
> 28-07-2011 22:11 3 file
> 28-07-2011 22:12 <SYMLINK> filelink [file]
> 28-07-2011 22:11 <JUNCTION> junction [F:\tst\subdir]
> 28-07-2011 22:10 <DIR> subdir
> 2 File(s) 3 bytes
> 5 Dir(s) 97.194.647.552 bytes free
>
> F:\tst>
>
> How can dir see the difference if they are supposed to be the same thing?
>
> My documentation says (if I remember correctly) they are stored in completely different ways: One as a specific NTFS object type and one as a reparse point with external data.
They are two different things, however...
Mount Points are Reparse Points
Junctions are Reparse Points
Directory Symlinks are Reparse Points
File Symlinks are Reparse Points
Junctions are not mount points are not directory symlinks are not file symlinks.
However, directory symlinks, file symlinks and junctions share common characteristics.
Both junctions and directory symlinks may point at directories. Junctions must
be absolute links. Mladen could rename c:\tmp to c:\tmp2 and the relative dir
symlink would not be broken, any junction or absolute directory symlink would be
broken. To support creating junctions, apr would have to translate relative links
into absolute links, possibly to the developer's surprise.
>From apr's own perspective, both must be reported as symlinks.
File symlinks and hardlinks both must point to files. Obviously ntfs cannot
distinguish between the original file and additional hardlinks. But using
Garrett's suggestion on win2003, we can (using an additional stream to tag
the canonical name of the file) for a faux-hardlinked softlink we create.
>From apr's perspective, both can be reported as symlinks.
Obviously, any create softlink feature of apr must distinguish whether the
target is a file or a directory, and while it is at it, it would be trivial
to work around permission issues using a fallback approach.
All of the above will be traversed in the same manner as unix symlinks.
It is agreeably stupid that create-symlink permissions were more narrow
than either hardlink or junction creation, but that is what we have.
Nobody is suggesting supporting .lnk files.
Please re-review Garrett's solution in light of this information.
RE: Researched and adapted pre-vista/2008 windows symlinks
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Mladen Turk [mailto:mturk@apache.org]
> Sent: donderdag 28 juli 2011 22:07
> To: Bert Huijben
> Subject: Re: Researched and adapted pre-vista/2008 windows symlinks
>
> On 07/28/2011 09:22 PM, Bert Huijben wrote:
> >
> >>
> >> So just asking, should we adopt this, before I start to work on it?
> >
>
> Attached a working solution :)
> The APR-zing should be quite simple
>
>
> > 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.
> >
>
> FYI on Vista+ symlinks *are* Junction points. Their limit is still 32 per dir.
> It just happens Microsoft created an nice API for making them.
F:\tst>dir
Volume in drive F is Projects
Volume Serial Number is 8817-32E5
Directory of F:\tst
28-07-2011 22:12 <DIR> .
28-07-2011 22:12 <DIR> ..
28-07-2011 22:10 <SYMLINKD> dirlink [subdir]
28-07-2011 22:11 3 file
28-07-2011 22:12 <SYMLINK> filelink [file]
28-07-2011 22:11 <JUNCTION> junction [F:\tst\subdir]
28-07-2011 22:10 <DIR> subdir
2 File(s) 3 bytes
5 Dir(s) 97.194.647.552 bytes free
F:\tst>
How can dir see the difference if they are supposed to be the same thing?
My documentation says (if I remember correctly) they are stored in completely different ways: One as a specific NTFS object type and one as a reparse point with external data.
Bert
RE: Researched and adapted pre-vista/2008 windows symlinks
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: William A. Rowe Jr. [mailto:wrowe@rowe-clan.net]
> Sent: donderdag 28 juli 2011 18:01
> To: APR Developer List
> Subject: Researched and adapted pre-vista/2008 windows symlinks
>
> http://fearthecowboy.com/2011/04/04/coapp-package-composition/
> http://fearthecowboy.com/2011/04/07/simulating-symlinks-for-windows-
> xp2003/
>
> For Windows 2003 directory-junction-symlinks and faux-file-symlinks;
> https://github.com/coapp/toolkit/blob/master/Win32/ReparsePoint.cs
> https://github.com/coapp/toolkit/blob/master/Win32/LegacySymlink.cs
> and the applicable license;
> https://github.com/coapp/toolkit/blob/master/License.txt
>
> We shouldn't be supporting 2000 and prior anymore... these would not
> work on FAT32 filesystems, but I believe NTFS has been the default
> for some time now (and FAT isn't an acceptable server filesystem).
>
> So just asking, should we adopt this, before I start to work on it?
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.
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.
E.g. how are you supposed to mix usage of a directory with applications that can handle real symlinks?
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.
+1 on implementing real Windows symlink support though.
Bert