[rfc] Proposal: fake symlinks support on windows

[Alexander Belchenko]

Aaron Bentley пишет:
> Alexander Belchenko wrote:
>> OK. I've update this specification and write first version of code to
>> deal with symlinks on windows in cygwin format.
>>
>> 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)
> 
> I was proposing two types of tree: fake-symlink tree and unix symlink tree.

I have uncertainty about this moment. I'm not sure, but preliminary 
thoughts lead me to conclusion that we need more than 2 types. See below.

> Under cygwin, we could use the Windows handling, and this would be
> better than the normal Cygwin handling, because it wouldn't create
> shortcuts.

I'm not sure, but I think it will be very non-trivial. Cygwin does not 
provide direct access to underlying Windows API, at least for Python. I 
really don't hack Cygwin too much, and this task probably forcing us to 
write C-extension for python.

But I'd like to implement first draft based on available python 
interfaces without C.

> I am quite confident that treating 'foo.lnk' as 'foo' will
> lead to problems sooner or later.

I agree. But it prevents to usual operations with symlinks on cygwin via 
cygwin UI rather than bzr UI. Is it good? Is in cygwin inside exists rod 
to switch off creating windows shortcuts? I don't know.

>> - MacOS WT ??? (I know *nothing* about Mac OS)
> 
> I think we can treat Macs as unix for this.
> 
>> And access from one system to WT checked out on another system should be
>> granted only with read-only restrictions. 
> 
> Why?

If you read comments in my code, you'll see that cygwin's symlinks is 
not simple files with special contents. Cygwin also intensively use 
windows files attributes. How you will control windows files attributes 
from within linux? Without this attributes cygwin treats those files as 
regular files, not symlinks.
And native cygwin's symlink to directory (that actually windows 
shortcut) require to use Windows COM. I don't know: is this mechanics is 
ported to linux?

My preliminary thoughts was: don't support mixed access to WT of 
non-native OS. Using fake symlinks only to make portability of tree 
between platforms. And not require to provide ability to actually 
changing symlinks on non-native WT checkout.


Here my current use case for which I want to implement fake symlinks 
support:

I have embedded system with OS Linux with Python 2.3 installed. I can't 
at this moment upgrade to python 2.4. All business logic stored in some 
sort of virtual disk that mounted to /home and provide main programs for 
my embedded system. This virtual disk is 2MB in size, and new versions 
distributed to customers via internet. I want to use bzr as version 
control and archiving tool. But I need to have support of symlinks to be 
able checkout versioned files to compare and/or change some of 
programs/scripts. Usually I will not change symlinks -- only change 
regular files. At this moment it's all. I need to import existing 
archives via SFTP to bzr repository that hosted on windows/cygwin 
machine and need to create utility to mirror state of arbitrary revision 
of tree onto native linux machine.

I'm become aware that there is more use cases. But creating too wide 
support of fake symlinks may be not worth big efforts. Because today bzr 
has another more actual problems.

>> 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.
> 
> Yes, I think so.
> 
>> So, do you can suggest me something about implementation? I think we
>> could provide some sort of tests for windows WT with symlinks.
> 
> I'll have to reply to this part later.

Well, tomorrow I will check how cygwin's symlinks looks on linux. I 
store them onto USB Flash disk and mount disk as vfat on linux. If you 
wish you can give me a hints what tests I could run.

--
Alexander