WRITTEN BY
/en-us/windows-server/blog/author/microsoft-windows-server-team
I had a comment from my last postabout the new SMB2 protocol that I wanted to follow up on…There was mention of support for ‘Symbolic Links’ in the post and Mr. Kevin Owen asked for some clarification. So, Kevin – straight from the developer who wrote the code:
In Vista/Longhorn server, the file system (NTFS) will start supporting a new filesystem object (examples of existing filesystem objects are files, folders etc.). This new object is a symbolic link. Think of a symbolic link as a pointer to another file system object (it can be a file, folder, shortcut or another symbolic link). So then you ask how is that different from a short-cut (the .lnk file)? Well, a shortcut will only work when used from within the Windows shell, it is a construct of the shell, and other apps don’t understand short-cuts. To other apps, short-cuts look just like a file. With symbolic links, this concept is taken and is implemented within the file system. Apps when they open a symbolic link will now open the target by default (i.e. what the link points to), unless they explicitly ask for the symbolic link itself to be opened. Note symbolic links are an NTFS feature.
Now why is this relevant to the SMB2 protocol? This is because, for symbolic links to behave correctly, they should be interpreted on the client side of a file sharing protocol (otherwise this can lead to security holes). SMB2 understands the concept of symbolic links and evaluates the links on the client. This is the support that is added in SMB2.0
– Ward Ralston
