Visible symlinks under Windows

James Peach jpeach at
Wed Feb 6 18:56:35 GMT 2008

On Feb 6, 2008, at 10:40 AM, Corinna Vinschen wrote:

> Hi,
> On Feb  6 09:37, James Peach wrote:
>> On Feb 6, 2008, at 3:27 AM, Corinna Vinschen wrote:
>>> While most Windws applications have no idea how to handle symlinks,
>>> that's obviously not the case for a Linux emulator.  However,  
>>> right now,
>>> due to the fact that Cygwin has no idea how to create a symlink on a
>>> Samba share, it always creates fake symlinks on a Samba share  
>>> which only
>>> work in the Windws environment, and it only recognizes symlinks as  
>>> files
>>> or directories, depending on the target of the symlink.
>> The Apple and Linux SMB clients have a format of storing a symlink  
>> in a
>> file. If you used this format, then you would be able to interoperate
>> symlinks created by these clients.
>> see smbfs_windows_readlink() and smbfs_create_windows_symlink_data()
> This file is only available for registered Apple ID owners.  I can't
> find a version on the net which is freely available and has these
> functions implemented, unfortunately.

AFAIK the free Apple developer membership should get you this:

I made a note of the file format here:

>>> We could fake an Extended Attribute which contain the symlink  
>>> information.
>>> When requesting a symlink's file information, it could return an EA
>>> called, say, ".smb.symlink".  The EA value consists of the relevant
>>> parts of the content of the stat buffer returned by lstat, plus the
>>> target path of the symlink in UNIX path notation.
>>> Creating a symlink could work by creating a simple file with an
>>> EA in the EA list, called, say, ".smb.symlink.create".  The value is
>>> the target path in UNIX path notation.  Given that ZwCreateFile  
>>> (and its
>>> SMB protocol counterpart) allows to define EAs at file creation  
>>> time,
>>> creating a symlink would be a simple one step operation.
>> This is a nice idea.
>> The advantage of Minshall+French symlink format
>> 	- it is already supported by other SMB clients
>> 	- it doesn't require server changes
>> 	- it works on Windows and Samba volumes
>> The main disadvantage is that it doesn't address your goal of getting
>> resolving actual symlinks that are on the server.
> Exactly.
> As far as the Windows client is concerned, we already have a method
> (actually two) of creating symlinks which works fine on a Samba share,
> as long as the symlink is utilized by the Windows client (especially
> Cygwin) only.  Using the above outlined method wouldn't add anything  
> new.
> The idea was to have a technique which allows to utilize real symlinks
> of the underlying file system and to recognize them as such by an
> initiated Windows application.  Since Cygwin is a Linux emulator  
> anyway,
> I think it makes sense to be able to recognize real symlinks  
> correctly.
> It knows what symlinks are, and it knows how to work with them.

In this case, the EA method doesn't buy you anything. Someone could  
already modify the server to recognise the existing symlink formats  
and translate them for real symlinks.

I do think that the EA technique you propose is much better that the  
various formats, it's just that there are already so many ways of  
doing symlinks. I guess SMB is the Perl of network protocols :(

More information about the samba-technical mailing list