Slashdot Mirror
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."
No, what is being discussed here is links, e.g., creating an additional filename referencing an inode.
4 1355
http://win32.mvps.org/ntfs/lnw.html
http://en.wikipedia.org/wiki/NTFS_symbolic_link
http://answers.google.com/answers/threadview?id=3
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.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
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).
Try this 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...
Symbolic links can also become outdated if the target moves. It's hard links that can't.
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):
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.
Kaetemi
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.
Survey research tool for commercial and scientific use
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...
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.
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' 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.
if you steal from one source, that is plagiarism, if you steal from many, well, that's just research.