Vista's Fake Symlink Support

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

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

[Brandon Live Veteran]

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

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

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

[Brandon Live Veteran]

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

[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: