Visible symlinks under Windows

[Corinna Vinschen]

On Feb  6 19:40, Corinna Vinschen wrote:
> >> 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.

Well, that's not quite right, of course.  It would add interoperability
with other SMB clients.  I guess I'll look into that additionally at
one point.  Thanks for the pointer.

> 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.


Corinna