Your Guide to the Latest Windows Server Product Information
I had a comment from my last post about 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
Unix filesystems, anyone? Your 'post' (or indeed that which you quote) should really have given credit to the original implementors, or at least mentioned them, shouldn't it? Windows users, eh.
Yipee! Windows invented the symlink. Or did it already existed on Unix/Linux, something like 15 years ago?
And yet another UNIX feature shows up in Windows as an "innovation".
Are these symbolic links paths (relative or absolute) like the *nix implementation or are they richer implementations that are much more robust like the Mac OS's aliases?
create a symlink, something i always missed on windows. what about all the other missing features in a os, seen in bsd, linux, unix, etc. maybe start here: http://unxutils.sourceforge.net/ and http://www.cygwin.com/, etc. bleh
"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)"
Are you nuts?!
For security to be maintained the filesystem (NTFS) has to parse the link and handle it appropriately! A symlink only has meaning within the system running the filesystem.
Either someone needs a big LARTing by a clue-by-four, I have seriously misred what you wrote, or you are ... not quite suitable to do this work.
I hope I seriously missed a point.
I feel it's worth mentioning to those who are not familiar with *nix, that symlinks have been available on various file systems in that space for... well, a very long time.
It's a long overdue addition to NTFS, and a very welcome one!
Those who don't understand UNIX are doomed to reinvent it, poorly
So did you stole this from BSD too?
>>...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
Will there be SMB2.0 clients for Windows XP/2000/etc or will we need Vista in order for network clients to properly access symlinks?
WinFS = UNIX FS 1970
Seems, like so much duplicated efforts now by microsoft at their kernel level, too bad they don't just do something like apple and use freebsd. At this point anyways, it seems like what microsoft is doing is essentially writing their own unix kernel.
But how do the new NTFS symbolic links differ from NTFS junction points?
Weren't hard links already in NTFS? I already use them to remap entire folders from Program Files on another drive (e.g. D:)