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

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.

NTFS already does it since Win2K !

[Anonymous Coward]

See here :

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

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

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 [wikipedia.org], for more info.

Re:NTFS already does it since Win2K !

[soikoban]

This was even posted on slashdot five years ago:
http://slashdot.org/article.pl?sid=00/03/02/083321 1&tid=109 [slashdot.org]
The links in the summary are broken though.

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 [sysinternals.com]

We can only hope

[n0dalus]

Since Windows programs have not ever needed to check for the existence of symlinks, a lot of software will be a serious DoS waiting to happen. Recursive symlink traversal is one of the most devastating things a computer can do to itself. It can damage hard drives, crash software, take down servers and generally make the computer unusable. On UNIX, almost all software is aware of this pitfall and won't go crashing the computer.

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 [bell-labs.com]

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:useful? really?

[xtracto]

does the average user *really* need them? I certainly can't remember ever having said 'Damn, I wish this piece-of-crap-OS would support symlinks' during my Windows days.

Man, you need to use symlinks to see how useful they are. As someone pointed before, symlinks are great to create compilations of files on a directory. Also, they are very useful if you want to use different types of libraries (DLLs) on different programs (in different directoires).

As for the "average user", as someone else said also, this symlink will surely help the file system Virtual folders or whatever is named. It is the same as the SQL oriented file system, you could ask, will the average user make use of SQL queries?, and the answer is that, they will, indirectley through the applications that are make use of that technology.

Remember, this symlink will be a feature of the FILESYSTEM, which will be used by the programs. I for one would preffer to have multiple symlinks to DLLS than to have to copy the libraries through all the hard disk (or maybe not DLLS but other files).

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.

Re:NTFS already does it since Win2K !

[DarkEdgeX]

If junctions only work on directories then you'd want to look at the CreateHardLink API [microsoft.com] (available in Win2K/XP/2003) which works only on files. You can create up to 1023 links to a single file using this API.

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:"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 [winsupersite.com]. 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

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 [theaimsgroup.com]), 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).

Re:Yet more great

[tpgp]

Its too late....

Five years to late [slashdot.org]

Re:NTFS already does it since Win2K !

[IWannaBeAnAC]

Hard links are different to soft links (symlinks). Hard links are two (or more) files that refer to exactly the same physical storage; rather than one file being a link to the other file, both links are precisely equivalent. This is completely transparent - multiply-linked files are indistinguishable from singly-linked files.

Soft links are represented as a special text file that contains the name of the linked file. The default behavior on opening a soft link is to redirect and open the target file instead. Alternatively, you can use readlink() to get the contents of the soft link directly.

Unix has had both kinds of link for aeons.

Re:No.

[nick8325]

Ha ha ha. Hilarious!

http://msdn.microsoft.com/library/en-us/fileio/fs/ createhardlink.asp [microsoft.com]

To be honest, I'm surprised it's only been there since Windows 2000.

Re:Lol, symlinks

[DrSkwid]

I can and will argue that

or rather, I'll just provide a link to this

The Use of Name Spaces in Plan 9

        Rob Pike
        Dave Presotto
        Ken Thompson
        Howard Trickey
        Phil Winterbottom
        Bell Laboratories, Murray Hill, NJ, 07974 USA

http://plan9.bell-labs.com/sys/doc/names.html [bell-labs.com]

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

[nick8325]

Well, there are reparse points (http://msdn.microsoft.com/library/en-us/fileio/fs /reparse_points.asp [microsoft.com]), which can act like symbolic links, but they only work on directories. There seems to be a program called Junction Link Magic here [rekenwonder.com] to make them.

Re:We can only hope

[countach]

>Any de1cent OS will detect an attempt to infinitely traverse a symlink, but what's it
>supposed to do?
>It can:
>
> * Close the program (= Possible data loss)
> * Slow the speed at which the program is allowed to access certain files (= Increase
>the chance of race conditions, sometimes by a lot. It doesn't really solve anything
>either)
> * Make the symlinks "disappear" after a certain level of recursion (= Inconsistent data)
> * Do nothing (= Solves nothing)

WTF.....

The answer is "none of the above". The open() call returns -1 with an error code of EMLINK, which if the program is any good will be passed onto the user as "Error opening file: Too many links", for the user to do with as he pleases.

>None of these options are as good as the software actually detecting the symlinks itself.
>When I say "most" UNIX software checks for symlinks, I am only referring to software
>which would otherwise be at risk of infinite recursion.

And what pray tell is the software supposed to do if it detects a symlink and/or a recursive one with special symlink handling code? All it can do is do report it to the user right? So why put in special code to do that? Just checking the return of open() and reporting the code to the user does the exact same thing.

More Dupe than you think

[TrentL]

I recall this [slashdot.org] Slashdot story from several years ago (damn, I can't believe a Slashdot headline has stayed with me that long). Sadly, the links referenced in the article are broken, so I don't recall exactly what it was about.

Already has this

[coolsva]

NTFS already has this and more
Reparse points (like links) http://msdn.microsoft.com/library/default.asp?url= /library/en-us/fileio/fs/reparse_points.asp [microsoft.com]
Junctions (to mount file systems) http://msdn.microsoft.com/library/default.asp?url= /library/en-us/fileio/fs/hard_links_and_junctions. asp [microsoft.com]
Sparse files (highly underutilized) http://msdn.microsoft.com/library/default.asp?url= /library/en-us/fileio/fs/sparse_files.asp [microsoft.com]
and of course the plain old short cuts that are really symbolic links in the traditional unix world.

I remember architecting a product to implement all unix based functionality in NT (IPC, memory mapped files, etc) and found NT40 to have that and more. Thats the time I really appreciated windows as a OS more mature than Unix.

The unfortunate part is people still think of DOS/Win95 code base when they think of windows. As a OS, W2K is much more mature in terms of the facilities they offer and as a filesystem, NTFS is way ahead.

Give me a feature in Unix and Im sure there is an equivalent in NT. Thousands of smart people working at Redmond are not idiots and millions of corporate architects proposing NT based solutions are not stupid either. They propose windows based technologies not just for looks (though end users do appreciate that).

Symlinks were a BSD invention

[Per Abrahamsen]

That the Research Unix guys didn't add it to Plan9 doesn't have to mean anything else than they suffer from the NIH syndrome. I don't believe symbolic links were ever a part of Research Unix.

The commercial product, SysV, got symbolic links, but they had to compete in the real world.

Re:Symbolic links?

[Anonymous Coward]

"Microsoft 'innovating' once again" - by el_womble (779715) on Monday October 31, @06:41AM

And, more "F.U.D." attempts by the 'pro-Unix/Linux/BSD' brothers @ "/.", as-per-usual... or, the usual "partially informed/incomplete data spouting rumor mill" is @ work here again, as-per-usual.

Take a read, so you are better informed:

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

-----

Win2K's version of NTFS supports directory symbolic links, where a directory serves as a symbolic link to another directory on the computer.

For example, if the directory D:\SYMLINK specified C:\WINNT\SYSTEM32 as its target, then an application accessing D:\SYMLINK\DRIVERS would in reality be accessing C:\WINNT\SYSTEM32\DRIVERS.

Directory symbolic links are known as NTFS junctions in Win2K.

Unfortunately, Win2K comes with no tools for creating junctions - you have to purchase the Win2K Resource Kit, which comes the linkd program for creating junctions.

I therefore decided to write my own junction-creating tool: Junction.

Junction not only allows you to create NTFS junctions, it allows you to see if files or directories are actually reparse points.

Reparse points are the mechanism on which NTFS junctions are based, and they are used by Win2K's Remote Storage Service (RSS), as well as volume mount points.

If you want to view reparse information, the usage for Junction is the following:

Usage: junction [-s]
-s
Recurse subdirectories.

If you want to create or delete a junction, use Junction like this:

Usage: junction [-d] []

To delete a junction specify the -d switch and the junction name.

-----

(NT's been there, & done that, ages ago already for DIRECTORY SYMBOLIC LINKS @ least... + the resource kit tools mentioned above, OR the tools offered by Dr. Russinovich & Bryce Cogswell @ SysInternals do the job in this matter as well as alternate methods of using what's already been in NTFS for ages now)

APK

P.S.=> "and giving the people what the want (10 years after everyone else). Go Redmond!" - by el_womble (779715) on Monday October 31, @06:41AM

They surely have, now, haven't they & for the last 12 years or more @ desktop/laptop levels up to Server OS + backoffice/industrial strength tools to match their Office Suite offerings + development tools?

So, with that statement of yours, I must agree:

Plus, 95%++ of the world's computers running Windows NT-based Operating Systems by now (e.g.-> NT/2000/XP/Server 2003), which run tons more hardwares than UNIX of any type does, + with more peripheral surrounding softwares for any imaginable purpose (thus, Win32 Os are far more ubiquitous + flexible) can't be TOO far wrong to second your statement now, can they? apk

The Fix: Aliases

[Rosyna]

Yes, the Mac OS had none of those problems with Aliases. I guess that's what happens when you design an OS from the ground up that doesn't use paths to reference everything. In fact, for a very long time there was no way to get a path in the Mac OS. OS X changed all that and now many programs are very fragile (like Preview).

Re:Symbolic links?

[Trelane]

Symlinks or hard links?

There is a huge difference between the two: a hard link is filesystem-level (simply a second entry in a directory to a file); a symlink is OS-level. One cannot cross filesystem boundaries (being filesystem-level), the other can.

Re:Symbolic links?

[SonicBurst]

I don't know where you got your info from, but plugging in a hotswap disk does NOT require a reboot, and hasn't since at least Windows 2000, but probably even NT 4. Open computer management, go to disk configuration, and click "rescan disks". It'll detect the drive just fine.

Re:Symbolic links?

[masklinn]

Windows 2k and above have both hardlinks (which are available via standard tools) as well as symlinks, restricted to directories only and not available via the OS' tools.

Check Juctions [sysinternals.com] for the creation and handling of symlinks.

Re:Already has this

[Anonymous Coward]

The drive letters are an alias and exist only for the purposes of legacy. Betas of WinFS have shown to completely disable drive letters as they are becoming less and less necessary. What you call C: is really \\.\HardDisk0\Partition0. Sometimes a dialog in Windows 2000 or XP slips up and actually displays the long full name instead of the aliased drive.

Now, with Windows 2000 and XP you might not be able to escape having a C: drive, as the OS expects it. But anything other drive that you add, including optical drives, can be mounted within that file system. I currently have three partitions and two optical drives. They are mounted as follows:

C:\
C:\Swap
C:\Documents and Settings\
C:\DVD
C:\CD-RW

Not suprising - any idea what NTFS 5 is capable

[soul_hk]

It seems people are forgetting about the "almost there" aspects of NTFS 5 ..

NTFS junction points are useful for alternate mounting.
The point of some key Windows Services are built for exactly this purpose .. Distributed Link Tracking and Object Identifiers
Reparse points are handy too ... http://support.microsoft.com/default.aspx?scid=kb; EN-US;q205524 [microsoft.com]

NTFS is a great file system, you just need to read the documentation..

Re:Different than shortcuts

[quantum bit]

OPEN(2) FreeBSD System Calls Manual OPEN(2)

NAME
          open -- open or create a file for reading or writing

LIBRARY
          Standard C Library (libc, -lc)

SYNOPSIS
          #include <fcntl.h>

          int
          open(const char *path, int flags, ...);

          The flags specified are formed by or'ing the following values
                      O_NOFOLLOW do not follow symlinks

Re:Lol, symlinks

[Paul Jakma]

Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file.

You're confused. Files in Unix filesystems have no hierarchy, with or without symbolic links. Files are quite independent of file names. Multiple directories may contain entries for the same file, the names need not even be the same. The same directory may reference the same file with multiple names. Note for examples that renaming a file changes the modification time of the /directory/, but not of the file.

Symbolic links are a bit of a hack though, yes. But mostly because they must expose the limitations of "files are not the same as filenames" - not because they allow multiple paths to the same file.

--paulj

Re:Symbolic links?

[masklinn]

The one fact you forgot to add that makes MS's current implementation poor is that the link becomes a drive letter, and how many in total can you have with Windows?

That would be really funny if it was true.

It is, alas, false, and junctions do not become "a drive letter", they are virtual folders akin to Linux' directory symlinks (since junctions sadly don't handle the file level but only the directory one).

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/ [swtch.com]

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

Re:Nevermind

[avdp]

Yes, you could essentially re-implement Explorer in every app written by having them handle the *.lnk files the way Explorer does. It sort of is counterproductive. It is much cleaner to have that in the filesystem (or at least the MS APIs to open files) so that it is transparent to apps. Frankly the way the shortcut thing was implemented is a ugly hack. I figured what happened is that they wanted the symlink concept, but didn't want to (or couldn't) change the filesystem. Looks like they're finally (10 years later) decided to do it right.

As far as users are concerned, I suspect they won't know/see the difference. Creating symlinks will just work like creating shortcuts.

 

Only on BSD and Linux... you want readlink.

[Ayanami Rei]

readlink (2) [opengroup.org]
NAME

readlink - read the contents of a symbolic link

SYNOPSIS

#include <unistd.h [slashdot.org]>

ssize_t readlink(const char *restrict path , char *restrict buf ,
size_t bufsize );

DESCRIPTION

The readlink() function shall place the contents of the symbolic link referred to by path in the buffer buf which has size bufsize. If the number of bytes in the symbolic link is less than bufsize, the contents of the remainder of buf are unspecified. If the buf argument is not large enough to contain the link content, the first bufsize bytes shall be placed in buf.

If the value of bufsize is greater than {SSIZE_MAX}, the result is implementation-defined.

RETURN VALUE

Upon successful completion, readlink() shall return the count of bytes placed in the buffer. Otherwise, it shall return a value of -1, leave the buffer unchanged, and set errno to indicate the error.

Re:More Dupe than you think

[Firehawke]

It's there, but they really didn't make much noise about it. I didn't even realize the tools were there until I found a webpage about it a few years back.

is one place to start. [microsoft.com]

Still, it'll be very nice to have real symlinks instead of shortcuts. It's what the shortcuts should have been all along.

Mac OS X already does it the RIGHT way.

[diamondsw]

A symlink is a hack (as many others have mentioned) that relies on pathnames to find a file. This is almost criminally STUPID, since if the file is moved or renamed, the link will break. If any of the intervening folders change, it will break. All sorts of fragility has resulted ever since where things cannot be moved or else links will break.

Mac OS X (and all the way back to System 7 in 1990) did it right by creating aliases which use a two-factor plan to locate its target:

1. Check the file-id. This is roughly the same as the inode, and will remain the same if the file is moved or renamed. If it's been moved or renamed, then update the path (see step 2).
   
2. Check the full pathname. Similar to a symlink. If the original file is deleted, but a different file is located where it was last seen, update the file-id.

Aliases also store sufficient information about the volume they were located on that the Finder can mount the volume automatically (if it's on the network) or inform the user of exactly why it didn't work. This also allows aliases to cross filesystems, which symlinks can but hard links cannot.

This is why symlinks are such a stupid solution on UNIX, since that OS has no excuse - aliases could have been trivially implemented due to the dual-layer nature of the filesystem (inodes separate from hierarchy).

(Now, I agree completely with how sucky it is that the shell does not support them, and that aspect has been sucky since day 1. However, that has nothing to do with alias technology and everything to do with shell implementation.)

Re:NTFS already had symlinks?

[Anonymous Coward]

NTFS has had hard links since the first version in 1993. Reparse points were added to NTFS in Windows 2000. These work like symbolic links, but can only point at directories, not files.

Re:We can only hope

[cortana]

Hmm...

$ ln -s argh argh

strace -e open cat argh
open("argh", O_RDONLY|O_LARGEFILE) = -1 ELOOP (Too many levels of symbolic links)

Honestly, there should be some kind of exam users should have to pass before they are allowed to post here.

Re:Funny thing is...

[Anonymous Coward]

The really funny thing is that nobody seems to realise that they were in Multics before Unix was even a gleam in Dennis Thompson's eye.

Re:NTFS already does it since Win2K !

[RhettLivingston]

Junction points, at least the ones created by the utility referred to, are in fact hard directory links. You can mount any directory from any NTFS volume as a directory at any point in any NTFS volume's tree, not just whole partitions.

I have used junction.exe many times to save a lot of reorganization by mounting a directory from one volume onto another when the other is full and there is no unallocated space to add. For example, you can move directories from "c:\Program Files" to "d:\Program Files" and then create junctions under "c:\program files" to the ones on d:. This will result in the associated programs running as if they had never been moved without any reinstallation.

Re:Symbolic links?

[mallardtheduck]

95%++ of the world's computers running Windows NT-based Operating Systems by now

Actually, 95% of the world's computers are embedded microproccessors, most of which don't even run anything classified as an "operating system", let alone windows. I expect that what you meant was that 95% of PC's are running Windows NT based operating systems. I doubt that, there are still plenty of older, pre-XP home machines in use today, so probably as many as 15-20% of PC's are running Windows 9x-based operating systems. You could have just said 95% of the world's PC's are running Win32-based operating systems, and you probably would have been correct.

Re:FOUR, er FIVE symlink styles, all kinda *wrong*

[Anonymous Coward]

As far as an application is concerned, there are only 3 different kinds of symlinks:

1. Object manager symlinks (1 and 5 are both drive letter mappings)
2. Filesystem symlinks (3 and 4 are both NTFS reparse points)
3. Application symlinks (shortcuts are imlemented by OLE)

If you're writing an end-user application, you probably only care about application symlinks if you care at all (because standard dialogs follow them for you). The advantage of shortcuts is that they can track their target if moved to another directory, or even to another computer!

If you are writing a system utility (such as backup or indexing) you have to pay attention to filesystem symlinks (like in Unix) because you can choose to follow them or not. But otherwise your burden is no different than without symlinks because the existence of hard links means that you already have to keep track of which filesystem/file number combinations you have already processed.

Now if you think that's bad, imagine how much worse it is on Unix. The proliferation of filesystems has made it so that you don't even know what's really a file and what isn't. Only a truly naive program would try to backup and restore /dev/kmem or /dev/sda0, what what about /proc? There's no function you can call that will tell you whether something is a real file or a virtual one, so your program is SOL.

dom