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

Comments

Different than shortcuts

[246o1]

From TFA, before it gets slashdotted and someone asks:

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.

"Virtual folders", I believe it's used for

[Sockatume]

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.

Re:"Virtual folders", I believe it's used for

[Hakubi_Washu]

Nope, those virtual folders are actually search-parameters saved in a xml-format, which is known already. Paul gets them wrong or at least gives a shitty explanation (he says these xml files store the results, but that wouldn't be dynamic as he claims as well), instead you click 'em and the search is fired up using the stored parameters, e.g. *.mp3

NTFS already does it since Win2K !

[Anonymous Coward]

See here :

http://www.sysinternals.com/Utilities/Junction.htm l

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 ? :(

Re:NTFS already does it since Win2K !

[TeXMaster]

Junction points on NTFS are neither symlinks nor hardlinks: they are mountpoints for system volumes (partitions). Basically, they are the way NT deals with the Unix way of doing things (instead of the DOS way of assigning letters to volumes).

NTFS does support hardlinks and, as the developers of the NTFS driver for Linux recently discovered (see details in this thread), it also supports symlinks, provided Microsoft Services For Unix are installed.

The important part of all this, is, I think, that open source tools ranging from the linux fs drivers (ntfs and cifs/smb) to the cygwin stuff should get updated and start managing the thing the way MS does it (on MS filesystems, of course).

No.

[Virak]

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.

NTFS already has symlinks, has done for years

[Anonymous Coward]

They are just not accesible from the shell. You need 3rd party utils to use them.. http://www.sysinternals.com/Utilities/Junction.htm l

Lol, symlinks

[DrSkwid]

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.

Re:Allow me to be the first to say...

[WWWWolf]

(Who was it who said: 'Those who don't know UNIX are condemned to recreate it. Badly.' ?)

$ fortune -m 'condemned'
...

Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer

And those who don't understand fortune(1) are condemned to ask about quotes =)

Re:We can only hope

[countach]

Bullshit. Most unix software is not aware of symlinks because it doesn't have to be. Generally, only system utilities care about the existance of symlinks. The OS will detect an attempt to open an infinitely recursive symlink.

Improve on symlinks?

[mcrbids]

There can be some improvement, particularly with managing symlinks.

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

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

Re:Symbolic links?

[b100dian]

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

Re:I think we have a new kind of troll...

[DrSkwid]

I try and keep them relevant.
This story is a case in point. Symlinks are a hack that hides the fact that disk drive based namespaces are a crock. And a crock that's easily solved.

Unix is 30 years old, Linux copies it. Windows is not in the picture.

Linux / BSD et. al. offers very little innovation any more. Instead anything new is coming in through the user space and we end up with stuff like GnomeVFS and smb:// handlers.

The only real place where any real Unix like innovation has occured in recent times was in Bell Labs and the expresssions of that are Plan 9 and Inferno.

You can try some of the concepts out in user space through http://swtch.com/plan9port/

"Plan 9 from User Space (aka plan9port) is a port of many Plan 9 programs from their native Plan 9 environment to Unix-like operating systems.
supported systems : Linux (x86 and PowerPC), FreeBSD (x86), Mac OS X (Power PC), NetBSD (x86), OpenBSD (x86 and PowerPC), SunOS (Sparc)."