Vista's Fake Symlink Support


Recommended Posts

Andareed

Symlinks themselves aren't the problem; the Vista SMB implementation is exhibiting this behaviour. However, it seems that you can easily enable symlink transparency through group policy.

Link to post
Share on other sites
Computer Guru

@Andareed: When I first read the reply above and at OSN, I though the same.

However, on closer inspection, it's not. Read it carefully. It says you can enable symlink transparency - yes. But for Vista clients only.

Also, it's not the SMB protocol, it's the fact that "NTFS 6" isn't NTFS 6 as promised - the filesystem itself doesn't provide the Symlink functionality or else there would never have been an issue since the filesystem wouldn't rely on a second API to translate symlink calls.

Link to post
Share on other sites
Brandon Live

The filesystem absolutely provides symlink functionality. It's done using reparse points - which are the NTFS standard way of doing hard links and junction points as well. If you have issues with how they're implemented over SMB then go ahead and complain. But don't lie to people and tell them that symlinks in NTFS are "fake."

Link to post
Share on other sites
Andareed

@Andareed: When I first read the reply above and at OSN, I though the same.

However, on closer inspection, it's not. Read it carefully. It says you can enable symlink transparency - yes. But for Vista clients only.

Also, it's not the SMB protocol, it's the fact that "NTFS 6" isn't NTFS 6 as promised - the filesystem itself doesn't provide the Symlink functionality or else there would never have been an issue since the filesystem wouldn't rely on a second API to translate symlink calls.

In order to resolve this, you need to figure out exactly how symlinks look different to normal files over SMB (e.g. via packet tracing). It's not clear whether the group policy setting has to be enabled on the server, client or both. If the client needs the setting, then obviously the server notifies the client (somehow) that it's dealing with a symlink. The article sights security issues relating to symlinks, so the developers may have decided to purposely break support for symlinks on XP for this reason. Or it's possible that symlinks set some file attribute that XP does not expect and this breaks things.

I doubt there is some second API. Most likely the SMB implementation looks for symlinks and sets a flag on the HANDLE to disable symlink redirection.

The title of this thread should be renamed to something like "Strange Behaviour of Vista Symlniks over SMB".

Link to post
Share on other sites
Andareed

I poked around and found that the kernel checks to see if the path (or part of it) is a symlink. If it is, it does some checks to see if (Local|Remote)To(Local|Remote) is allowed against how the file is to be accessed (e.g. client reading file from server). If the check fails, the kernel returns STATUS_SYMLINK_CLASS_DISABLED. Since the check appears to be done on both client and server side, the smb server must notify the client of such symlinks, which I suspect breaks XP and SAMBA.

Link to post
Share on other sites
Brandon Live

Yeah, and my point was that an updated Samba client would handle them just fine.

Link to post
Share on other sites
ichi

Yeah, and my point was that an updated Samba client would handle them just fine.

Ok, so basically what we have there is a symlink implementation that, unlike the unix one, must be handed client side, right?

That is, a crippled implementation that cannot be cleanly adapted to any non-vista environment, and hence either a bad idea or a lame attempt to add another reason for people to switch to vista (probably both).

So much for interoperability :rolleyes:

Link to post
Share on other sites
This topic is now closed to further replies.
  • Recently Browsing   0 members

    No registered users viewing this page.