Slashdot Mirror
Vista To Get Symlinks?
TheRealSlimShady writes "According to a post by Ward Ralston on the Windows server team's weblog, Vista server is to get symlinks as part of the SMB2 protocol." From the post: "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)."
...is a compliment of the highest form.
innovation from MS.
Welcome to the 1980s, Microsoft.
(Who was it who said: 'Those who don't know UNIX are condemned to recreate it. Badly.' ?)
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
Although the moon is smaller than the earth, it is farther away.
Some of the Vista previews have shown off things dubbed "virtual folders" which work in a similar way to browsing by artist or album in the current version of Media Player. You can manipulate the files like it's a normal folder window, yet the actual files may be scattered over different folders and drives. Presumably it's an effort to make managing large amounts of music/video outside of Media Player easier. They almost certainly use these symbolic links. They're a bit different from shortcuts.
No kidding!!! What do you say at this point?
From TFA:
"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). "
Is it not rather:
"If the client does not interpret symbolic links then nothing will work?"
See here :
m l
;-)
:(
http://www.sysinternals.com/Utilities/Junction.ht
Any feature new in Vista but the look and feel ?
What about booting the OS with less than about 20 services started and 256MB of memory used ?
Shortcuts are just ordinary files that, when opened, open the location it points to. A symlink, however, allows you transparently access it as though it were the actual file/folder; "C:\Shortcut to porn\hot lesbian action.jpg" won't work, whereas "C:\Symlink to porn\hot lesbian action.jpg" will. See the Wikipedia entry, for more info.
that in about 2 years time, everybody will be running around saying that MS developed it, and that *nix copied it. Just the way it works.
I prefer the "u" in honour as it seems to be missing these days.
The inventors of Unix scrapped symlinks when they did their next OS
Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file. This ambiguity is a source of confusion, especially since some shells work overtime to present a consistent view from programs such as pwd, while other programs and the kernel itself do nothing about the problem.
http://plan9.bell-labs.com/sys/doc/lexnames.html
NT *was* going to have executables that pretended to be files, i.e. when you opened the executable to get the contents it would run and return the output rather than the by bytes of the executable, with a special NT syscall to read the *real* contents. Kind of like a named pipe. I was looking forward to this but it didn't work out.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
We are the leaders, wait for us!
I don't believe that the word innovate was used anywhere except here on slashdot. While it's been a long time coming, the blog entry that originally posted this admits that all these additions are addressing limitations in SMB.
It's not like Linux never copied an idea from another OS, yet it seems MS is not allowed to add a feature unless they thought of it themselves.
But then I guess everyone here gets a bit bitter when there is one less thing to complain about MS.
No France
oops, isnt there still:
Make that FIVE ways. All of them looking somewhat alike, but all with subtly different syntax, semantics, overhead, and security implications. Sweet!
There can be some improvement, particularly with managing symlinks.
/usr/tunes to /usr/local/tunes. Later, you symlink /usr/local/tunes/YMCA.mp3 => ~/my_favorite_song.mp3. Now, you have a symlink that relies on both the existence of "/usr/tunes/" AND symlink "/usr/local/tunes >> /usr/tunes". Thus, while deleting 1st ("/usr/local/tunes => /usr/tunes") symlink doesn't actually delete anything, it does cause ~/my_favorite_song.mp3 to become unworkable.
1) When you move a destination object, symlinks don't follow the target . This leaves "broken" symlinks that refer to nothing. Why doesn't the mv command move these too?
2) When you symlink a symlinked folder, the root symlink is ignored. Let's say you symlink
3) Symlinks cause all kinds of weirds around chrooted file systems , especially ones on a different underlying filesystem. If you're not very careful, nothing is as it seems! Files go nowhere, files are accessable only sometimes, etc. It's logical when you understand and appreciate a symlink for what it is, just a referral, but it can be maddening when security contexts get distorted around a chroot...
I have no problem with your religion until you decide it's reason to deprive others of the truth.
...is a compliment of the highest form.
NTFS already had symlinks. Just that Explorer and cmd.exe didn't used the feature. But if created (with a third party tool) they are properly used.
Also, FAT had initially a flag indicating that an object is not a file, nor a folder, but a symlink. Unfortunately, the attribute got later used as a "Long Filename Part no. X" flag... talk about bad design..
gtkaml.org
Well. So does FAT, except it is called a crosslink, and aparently scandisk and various disk defragmentation tools do not handle it correctly ;-)
The whole point of symbolic links is that they're transparent. That way, an application doesn't have to parse a .lnk file. The OS handles reading/writing from the correct file. Real file symlinks have been missing from Windows for too long, I think it's about time they were added. (Whether or not anybody actually uses them instead of shortcuts is another story.)