Visible symlinks under Windows
corinna at vinschen.de
Wed Feb 6 18:48:47 GMT 2008
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.
> 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.
More information about the samba-technical