Visible symlinks under Windows

[James Peach]

On Feb 6, 2008, at 3:27 AM, Corinna Vinschen wrote:

> Hi,
>
>
> as Cygwin developer, it's sort of frustrating that there isn't a way  
> to
> identify symlinks on Samba shares from a Windows user space  
> application
> for what they really are.
>
> 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.

http://www.opensource.apple.com/darwinsource/10.5.1/smb-345/kernel/fs/smbfs/smbfs_vnops.c

see smbfs_windows_readlink() and smbfs_create_windows_symlink_data()

> If there would be a way to identify a symlink and to create real
> symlinks on a Samba share, Cygwin would happily handle them.
>
> So I'm wondering, is there any interest to implement another extension
> along the lines of the changes to the SMB_FS_OBJECTID_INFORMATION  
> reply,
> which would allow a "knowing" Win32 application to retrieve the actual
> symlink file information as well as allowing it to create real  
> symlinks?
>
> If so, the question is, how could that be done?  I had the following  
> idea:
>
> 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.