Vista's Limited Symlinks

An anonymous reader writes, "Symlinks haven't really been added to Windows Vista. It seems that the calls to the Windows Vista symlink API only occur during the creation of such files or when accessing them from Windows Explorer. What this means is, you can't access symlinks from another OS. To be fair, you probably didn't expect to be able to dual-boot into XP and suddenly have access to the symlinks you created on the Vista partition earlier that day. But then again, you probably expected to be able to access these symlinks through a network share/UNC path or as files on a webserver. But you can't." From the article: "Clearly, Vista's symlink API isn't complete — hopefully this is something that can be patched via a hotfix and that we don't have to wait for Fiji to get something as simple as UNC support built in."

Re:Shortcuts are nothing new

[kimvette]

No, what is being discussed here is links, e.g., creating an additional filename referencing an inode.

http://win32.mvps.org/ntfs/lnw.html [mvps.org]
http://en.wikipedia.org/wiki/NTFS_symbolic_link [wikipedia.org]
http://answers.google.com/answers/threadview?id=34 1355 [google.com]

NTFS does support links, but as usual from Microsoft, it's half-baked and only the bare minimum required for POSIX compliance was implemented. From sysinternals (now a Microsoft site) you can download a utility for manipulating NTFS links, or you can install the free Services for Unix (again, from Microsoft's web site) to get the M$ version of ln.

Junctions

[wandazulu]

I can't RTFA because of web error, but while I haven't tried Vista's idea of symlinks, I have used junctions, which were introduced in Win2000. To me, symlinks are one of the best features of Unix and on my Mac and Linux machines, I use them quite extensively. On Windows, while the junction API was available, no Microsoft-specific tools made use of them (that I could find), and resorted to a freeware program that implemented the junction api.

Whoa, big mistake. Junctions *do* work, but, and I think this is why Microsoft didn't promote or encourage their use, none of their other tools support them. In other words, doing a search of a drive that has junctions can lead to infinite recursion depending on how the junction is created. No Windows tools understand the "Don't follow symlinks" command that Unix tools have, and I had a few programs even crash whenever I tried to save to a junctioned-folder (Visual Studio was guaranteed to crash on me).

don't use NTFS

[drgonzo59]

Ext3 has great symlink support ;)

Try this [fs-driver.org] and a ext3 file system. I have all my Documents and the whole user directory on an ext3 and it works great. I can also access it from Linux if I want...

Re:Shortcuts are nothing new

[Anonymous Coward]

No, what is being discussed here is links, e.g., creating an additional filename referencing an inode.

That would be a "hard link". Grandparent was right, sym(bolic) links (unix "ln -s") are like shortcuts: rm the symlink and you don't erase the file it was linking too (whereas you would if the link was referencing the same inode). The only difference is that Windows Vista now implements symlinks directly in the filesystem instead of through .lnk files.

Re:Shortcuts are nothing new

[emurphy42]

Symbolic links [wikipedia.org] can also become outdated if the target moves. It's hard links [wikipedia.org] that can't.

Re:Huh? Symlinks were in XP/2000 NTFS all the time

[ozzee]

At first blush you would think so, but the semantics of a windows NTFS symlink is more like a mount point.

Firstly, you can't use normal "commands" to create/delete NTFS symlinks. The collection of system calls to create a symlink are badly documented and incomplete.

The big differences are (from memory):

• If you attempt to delete an NTFS symlink using normal "remove" system calls, you delete the file being linked to.
• If you rename a symlink, you're renaming the file being linked to.
• There are no "relative" symlinks (i.e. ln -s x y)
• In *nix, if xxx is a symlink to a directory then xxx refers to the symlink while xxx/ refers to the location linked to
• ... probably more, I can't think of anything else right now, I'll go do some more research later.

So while there is a similar function called a "reparse point" it is more like "mount" that it is like a a true UNIX symlink.

Also, most of the Windows tools just don't deal with link (hardlinks or symlinks). If you do a hardlink from one file to another and check to see disk usage of a directory, the file is counted twice. Most unix tools (du etc) will not count hardlinked files twice and symlinks are counted as the disk space the symlink uses not the file it points to.

Symlinks are a very powerful tool and are very mature in the *nix world. Windows is just simply way behind on this one.

Re:Windows' FS / the alternate universe story

[Kaetemi]

drive letters are just silly

You don't really need to use them. In Windows you can perfectly access the volume where you installed it by simply using "\". You can also mount a volume to a folder, Control Panel > System and Maintenance > Computer Management > Disk Management > Right Click a Volume > Change Drive Letter and Paths > Add > Mount in "\blahblah" (make sure you first create the folder) > OK, and then you can just access that volume without using drive letters by doing "\blahblah" (at least, it seems to be working that way here, on vista), and you can also access these volume folder thingies from the network if it or it's parent's folder is shared. :)

If they would have kept their original ideas

[Iloinen Lohikrme]

I remember back from the beginning of 90's, around the time when Windows NT 3.11 came to markets, that vision behind NT was that it would be as modular as possible and allow swapping of lots of components beginning from the kernel to file-system. This was actually reported in lots of computer news papers, but it seems from now that it was just hype and hopeful wishes. Now it seems that the code base of NT and it's successors is so mingled that trying to swap components from it would make the system die in a split second.

Re:don't use NTFS

[drgonzo59]

Subjectively it works great for me, I copy large media files and visibly it works no slower than a corresponding NTFS or FAT partition did. However I did not benchmark it exactly so it could be slower. Shoot the author an email and ask him, nobody knows the internals of the driver (and the possible speed penalties) better than them.

The only thing I would be worried is corruption not speed. I have never had problems, but I would not put a financial database on it either, just because it is somewhat new and "experimental"...

Re:Windows' FS / the alternate universe story

[drgonzo59]

There is not obsession with UNIX there is obsession with "common sense", security, stability, reliability. UNIXes at the moment fit that list most of the time. Tomorrow it could be Plan9 or QNX or some other exotic thing, I don't care. I am not a more Linux fanboy than I am a Windows fanboy or a Honda or Wal-Mart fanboy I just use what makes sense at the time (yap, sorry no brand loyalty at all here).

I mean, they could always port GNU userland over to the NT kernel, but dont MS already do that (or something similar) in their UNIX resource thing, which you can download.

You are referring to POSIX I presume. Well, have you seen any native Unix code running on Windows lately? I didn't! Windows POSIX compliance is a joke, it was more of a marketing ploy to tell their client ("we even run Unix!") but in reality it is very broken. That is why you have Cygwin...

Re:Shortcuts are nothing new

[listen]

If you rm a one link to an inode, (or close a file descriptor), it reduces the inodes usage count by one. When the count reaches zero, the blocks referenced by the inode are marked free. The behaviour you describe would be utterly horrendous.

Re:Shortcuts are nothing new

[Ucklak]

It also sounds like a puppy granting wishes but that isn't what the article is about.

That so called "shortcut" feature that has been around since Windows 3.1 isn't a 'link [wikipedia.org]' as it works on POSIX complaint systems. It is a shortcut that gives the user - not the computer - a quick way to access a directory. It cannot handle I/O functions.