Want to map symbolic links as Windows Shortcuts

[Green, Paul]

Scott Gifford [mailto:sgifford at tir.com] writes:

> "MCCALL,DON (HP-USA,ex1)" <don_mccall at hp.com> writes:
>
> [...]
>
> > I don't THINK you would want Windows to treat UNIX symbolic links as
> > if they were 'shortcuts.  If you WERE able to, Windows would
> > probably throw up, because it would expect to get a LOT more
> > information from that 'shortcut' than is actually there; evidence
> > the properties that you can access by 'rightclicking' on a REAL
> > windows shortcut file....
>
> There are some other reasons you may not want Windows/Samba to do
> this.  [A] It's possible for symlinks on the Unix side to point to files
> outside of the shared part of the filesystem; Samba will resolve
> these, and serve up the appropriate file or directory.  [B] It's also
> possible for Windows shortcuts stored on a Samba share to point to a
> local file on the user's hard drive.
> 
> Both of these would be very tricky to deal with automatically.
> 
> ----ScottG.

[A] Mindful of the comment from Christopher R. Hertel [crh at nts.umn.edu] that
the "follow symlinks" parameter can control link-chasing today, I would also
point out that smbd is running with the effective access (UID,GID) of the
user making the access request.  Therefore, even if Samba follows a symlink
on the Unix side off to another location, I don't see how it can grant
anyone access they didn't already have.  Or am I missing something here?

[B] This is already true today. Anyone can use Windows to create a Shortcut
on a Samba drive.  What was it that you (Scott) were worried about here?

The actual case I was seriously considering implementing was dynamically
creating shortcuts when Samba found a symlink to a directory. As a test, I
created a Windows Shortcut to a directory and there isn't much to it. Most
of the complex data that is saved with a shortcut is greatly simplified when
the target is a directory.

(Of course, Windows prefixes the directory name with the drive letter, as in
U:\pub\vos\vc.  Samba wouldn't know the drive letter, and each user could
have a different drive anyway, so it wouldn't be practical to use a drive
letter.  Samba would have to use a UNC name of the form \\share\path.  These
DO work in shortcuts).  

I think the sticky part of this project would be trying to discover the
reverse situation, when the Windows client was creating a shortcut, and
having Samba map that to a new symbolic link.  Even if this only happened
for directories, it still seems rather iffy.  I don't like having to
recognize and decode file contents on the fly, and I don't like the idea of
a magic suffix. And without two-way, reversible, mapping, it isn't clear to
me that this project is worth much to end users. Sigh. Never mind.

PG
--
Paul Green, Senior Technical Consultant, Stratus Computer.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.