[rfc] Proposal: fake symlinks support on windows

[Alexander Belchenko]

Aaron Bentley пишет:
> Alexander Belchenko wrote:
>> I propose reuse cygwin format and gain full compatibility with cygwin.
>>
>> I propose to make special methods in bzrlib/osutils.py module:
>>
>> bzrlib.osutils.readlink  -> extract file path from fake symlink
>> bzrlib.osutils.symlink   -> create fake symlink
> 
>> that will simulate work with symlinks for native windows. This methods
>> for all other systems that has support of symlinks should be
>> transparently directed to
>>
>> bzrlib.osutils.readlink = os.readlink
>> bzrlib.osutils.readlink = os.symlink
> 
> I don't think they should go there, because if we switch on platform, 
> *nix won't handle these symlinks properly (i.e. if the tree is created 
> by Windows, then accessed by *nix.)
> 
> I think the symlink-handling approach should be per-working tree, and 
> that *nix should use this style when working with a tree that was 
> created by Windows.
> 
> I think your proposal can be usefully combined with 
> http://bazaar-vcs.org/WindowsSymlinkSupport

OK. I've update this specification and write first version of code to 
deal with symlinks on windows in cygwin format.

> That sounds doable.  It's nice that it will work with cygwin's symlink
> implementation, though of course cygwin doesn't need special support 
> from bzr.

Now I have some questions about how to implement symlinks support. Your 
note about WorkingTree and access to faked symlinks from another OS will 
guide me to the thought that we need to have some different sorts of 
WorkingTree (WT):

- universal WT for all platforms, when there is no symlinks in tree
- Unix WT with unix symlinks
- Windows WT with cygwin symlinks
- Cygwin WT with cygwin symlinks of 2 kinds (symlink to file as plain 
file, and symlink to directory is windows shortcut)
- MacOS WT ??? (I know *nothing* about Mac OS)

And access from one system to WT checked out on another system should be 
granted only with read-only restrictions. Actually it's should depends 
on the filesystem in which WT live. But detecting filesystem type might 
be non-trivial problem. So, simple solution could be is keeping in 
.bzr/checkout some special info about subtype of WT 
(universal/unix/windows/cygwin/macos) and create methods to extract 
symlink target in different combination WT + OS.

I suppose that combinations will be as following.
Legend: rw - read/write, r - read-only, '?' - i'm not sure

WT  \  OS   | unix | windows | cygwin | macos
------------+------+---------+--------+-------
universal   |  rw  |   rw    |   rw   |   rw
unix        |  rw  |   ?     |   r?   |   ?
windows     |  r   |   rw    |   r    |   r?
cygwin      |  r?  |   r     |   rw   |   ?
macos       |  ?   |   ?     |   ?    |   rw


As first step I propose make simple solution and restrict access to 
non-universal WT only on the same OS -- as in my table above 'rw' means 
read-write access. On another OS user should checkout WT again to get 
full control via symlinks.

It also require to write plugin to control symlinks targets on windows. 
It's not problem.

So, do you can suggest me something about implementation? I think we 
could provide some sort of tests for windows WT with symlinks.

--
Alexander
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: win32_symlinks.py
Url: https://lists.ubuntu.com/archives/bazaar/attachments/20060518/b2297aa0/attachment.diff