Home > Windows > Vista’s Symlinks Revisited

Vista’s Symlinks Revisited

  Submitted by Dolphin Windows 28 Comments

“It’s not often that something we classify as a ‘really good’ feature turns out to be a bit of a sham, but unfortunately, that’s the case with Vista’s symlinks. Just a couple of days ago, symlinks were our ‘big Vista feature of the week’, but now, we’re not so sure.”

About The Author

Thom Holwerda

Follow me on Mastodon @[email protected]

28 Comments

  1. 2006-11-19 12:04 am
    Anonymous

    The author is clueless. Read the following:

    “If your buddy at work has the latest documents for the project you’re both co-working on in his shared documents folder symlink’d over to the actual path (so he doesn’t have to manually synchronize the directories nor remember to keep changing permissions on shares), you can’t get it from your XP workstation.”

    NO symlink implementation works that way. Symlinks are relative/absolute to the local drive. If there is a symlink pointing to /home/tom/project.doc in a shared directory on the network, and Bob over in Accounting wants to take a look at it, when he opens the symlink, HIS LOCAL SYSTEM will try to read “/home/tom/project.doc” — which of course doesn’t exist.

    Author needs to learn what symlinks actually are.

    • 2006-11-19 12:12 am
      smitty_one_each

      Your assertion may hold true.

      However:

      They’re not a part of the (allegedly) revised NTFS filesystem, and as far as we can tell, they’re not well-incorporate into the kernel either.

      How is it that a feature that is clear, simple, and obvious in *nix has to be a challenge for Redmond?

      Is there some patent challenge rationale for not just implementing the file equivalent of a pointer? WTF, K.

      • 2006-11-19 5:42 am
        n4cer

        They’re not a part of the (allegedly) revised NTFS filesystem, and as far as we can tell, they’re not well-incorporate into the kernel either.

        As the first poster said, the article’s author is simply clueless. There’s nothing alleged about the file system modifications. It’s the reason why symlinks can’t be evaluated on older versions of Windows.

        A couple of minutes of searching would’ve given him information about symlink evaluatetion and their default behavior on Windows.

        Q: So then, what is the difference between a shortcut and the links?

        A: A shortcut is a file implemented by Shell32 via the IShellLink interface. These files tell shell to jump to a different location. A symbolic link is implemented under the filesystem API, so regular applications calling CreateFile get the benefit of links without needing to implement their own code, as they would with IShellLink.

        Q: What is the difference between a junction point, and a directory symlink?

        A: Junctions and directory symlinks have subtly different semantics. For example, symbolic links are always evaluated on the client in a network scenario, whereas junctions are evaluated on the server. Also, ACLs are handled differently too. However, they are broadly similar.

        Q: Should I be able to access a symlinked folder via the network?

        A: Yes, remember that the client and the server needs to be Vista. By default only local to local links are turned on. You would need to enable the Local to Remote symlinks through the policy editor.

        https://blogs.technet.com/filecab/articles/457811.aspx

        Checking the Group Policy Editor in Vista (gpedit.msc) as advised above yields the following option under Computer Configuration | Administrative Templates | System | NTFS File System:

        Selectively allow the evaluation of a symbolic link

        o Not Configured (Default)

        o Enabled

        o Disabled

        [] Local Link to Local Target

        [] Local Link to a Remote Target

        [] Remote Link to a Remote Target

        [] Remote Link to a Local Target

        Explaination:

        Symbolic links can introduce vulnerabilities in certain applications. To mitigate this issue, you can selectively enable or disable the evaluation of these types of symbolic links:

        Local Link to a Local Target

        Local Link to a Remote Target

        Remote Link to Remote Target

        Remote Link to Local Target

        For further information please refer to the Windows Help section

        NOTE: If this policy is Disabled or Not Configured, local administrators may select the types of symbolic links to be evaluated.

  • 2006-11-19 12:32 am
    tscholz

    Symlinks (on unix atleast) works at filesystem level, and are parsed by system calls. And since a “file share” is usually done through a daemon like samba or apache. The daemon uses system calls to read files, and can access symlinks just fine. The application can choose to ignore symlinks, which apache does with an option. But if the application is ignorant of the concept of symlinks, it will not know the difference between the symlinks and the real file.

    What you describe would be true with something like the shortcut feature in Windows.

    • 2006-11-19 12:59 am
      rayiner

      No, he’s right. Symlinks are usually just a file containing the path of the real file (or that data stuffed into the inode or something along those lines). They are always interpreted relative to the local namespace. The only way that scheme would work is if the real path of the work directory happened to be the same on both machines. If the shared folder was /home/rayiner on one machine, and /mnt/rayiners-machine/home/rayiner on the other, the symlink wouldn’t work.

      • 2006-11-19 1:05 am
        wirespot

        People, what are you smoking? There’s no bloody way you’re going to get a symlink on a remote filesystem refer to an actual file on your local filesystem! It’s been said above, I’ll say it again: to the one accessing remotely, symlinks look just like real files. The daemon serving the files (Samba, Apache) will translate them on the fly.

        • 2006-11-19 6:45 pm
          kokara4a

          Well, NFS seems to be an exception. A symbolic link on a remote share is treated as local to where it is mounted from. It has to be like that otherwise you will not be able to create symbolic links on a remote filesystem. I guess other networked filesystems of Unix breed will do the same.

      • 2006-11-19 1:16 am
        tscholz

        While it’s true that it is just a file that points to the real file, it’s all about who interprets it. If it has to be done by the application that opens it (like windows shortcut), or by the kernel/filesystem. On most unix platform, if i’m not mistaken, symlinks are done by kernel/filesystem. So the application does not have to know that it’s opening an symlink.

  • 2006-11-19 3:06 am
    fsckit

    NO symlink implementation works that way.

    Alright smart guy.

    This is an nfs share

    jamesb@odin:~$ df -h

    Filesystem Size Used Avail Use% Mounted on

    thor:/home/jamesb/share

    254G 139G 102G 58% /fileserv

    This is a symlink working just fine over a network mount.

    jamesb@odin:~$ ls -l /fileserv/asymlink

    lrwxrwxrwx 1 jamesb jamesb 10 2006-11-18 22:03 /fileserv/asymlink -> backup.tgz

    Any questions?

    • 2006-11-20 6:22 pm
      squainter

      Actually, this synlink could work because the file it points to is relative to the link. So, if you mount this on a remote client, the target will still be relative to the mount point, regardless of the mount point itself. However, if you pointed your link to a file in another part of the filesystem, the link will fail, because, as was pointed out before, the client interprets the link path depending on what the server reports. So, if the server says that the file foo.txt points to another file called /etc/sfw/bar.txt, then that path needs to reside on your client (which of course you could NFS mount to the client as well). The nice thing about Unix symlinks, which are the only sort I’ve ever worked with, is that they are brain-dead simple. They are only inodes containing the path to the target file, which is then opened once the system realizes the first file was a link. Simple. And the nice thing about NFS is it simply presents directory contents to the client as if they were local. No magic. If the file’s there and you have permissions to open it, you can open it. If it’s not there, or you have no permission to do a read, you’re out of luck. Who would expect anything else?

  • 2006-11-19 4:36 am
    Archangel

    NO symlink implementation works that way. Symlinks are relative/absolute to the local drive. If there is a symlink pointing to /home/tom/project.doc in a shared directory on the network, and Bob over in Accounting wants to take a look at it, when he opens the symlink, HIS LOCAL SYSTEM will try to read “/home/tom/project.doc” — which of course doesn’t exist.

    You’re wrong. I just had a quick test of this, by creating a symlink /tmp/vt to /var/tmp. Sure enough, when browsing through Samba, I can happily follow that symlink and see the contents of my /var/tmp folder (on the server, _not_ on the client).

    Obviously it is up to the network FS implementation how it handles symlinks, but I’d tend to think that on a Unix-type system they’d probably ‘just work’ as you expect, because they’re being handled transparently by the filesystem – most operations on the link look exactly like there really is a directory there.

    Whereas it seems Microsoft’s done some dodgy hack to get them into Vista, but because of that it’s not really universal. At this point, I can’t even muster up any surprise at that.

    Edited 2006-11-19 04:37

  • 2006-11-19 5:00 am
    Dolphin

    Author needs to learn what symlinks actually are.

    I guess someone needs to learn to do a bit of quick research before commenting. I guess we know who “Anony” that commented immediately with offensive language on the article in question. People like you make me sick.

    Test it for yourself and see what symlinks actually are, as you say. Do your research first, then put your money where your mouth is.

    The sad thing is, you had a 5 rating for a completely BS reply that made no sense and was completely made-up. You obviously never read a thing about Symlinks, and didn’t bother to test your “theory” out, yet quite a few people believed you and thought you were saying something that made sense. Yuck.

  • 2006-11-19 12:13 am
    Bajan

    Article seems a bit of a rag.Quit b****ing at least it got out the door on time as promised.

  • 2006-11-19 12:31 am
    vicious1

    yea the article seems to be a little bit of a … well.. ;)

    But I am wondering really what Vista will turn out as after a while and once people (read: power users) are really using it and start finding the quirks.

    I think once Vista Retail hits the market we will have some very interesting times ahead. I just hope not everyone on the planet will write a “Vista review”. They should just have a central image server were all the “reviewers” can link to ;)

    //FR

    http://blog.2blocksaway.com

  • 2006-11-19 2:13 am
    eantoranz

    Sarcasm: These guys are obviously in danger because of unix IP infringement. I bet “cousin’ stevie” doesn’t know about it, or symlinks wouldn’t have made it to Vista.

    Edited 2006-11-19 02:21

    • 2006-11-19 2:34 pm
      CowMan

      You’ve got this all wrong. They’re only implementing symlinks so they can sue the pants off anyone who uses them on a non-windows platform.

      It’s not like they are going to care how frivolous the suits are anyway ;)

  • 2006-11-19 3:09 am
    NotParker

    http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html#s…

    “Symbolic Links are to files what Junctions are to folders in that they are both Transparent and Symbolic. Transparency means that an application can access them just as they would any other file, Symbolism means that the data objects can reside on any available volume, i.e. they are not limited to a single volume like HardLinks. Symbolic Links differ from Shortcuts in that they offer a Transparent pathway to the desired data object, with a shortcut (.lnk), something has to read and interpret the content of the shortcut file and then open the file that it references (i.e. it is a two step process). When an application uses a symlink it gains immediate access to the data object referenced by the symlink (i.e. it is a one step process).”

    “The NTFS file system implemented in NT4, Windows 2000, Windows XP and Windows XP-64 supports a facility known as hard links (referred to herein as HardLinks). HardLinks provide the ability to keep a single copy of a file yet have it appear in multiple folders (directories). They can be created with the POSIX command ln included in the Windows Resource Kit or the fsutil command utility included in Windows XP. Thus, using standard Windows facilities HardLinks can only be created at the command prompt, which can be tedious, especially when HardLinks to multiple files are required or when one only makes occasional use of HardLinks. Support for Junctions in standard Microsoft software offerings is even more limited than that offered for HardLinks.

    Link Shell Extension (LSE) provides for the creation of HardLinks , Junctions , and Vista’s Symbolic Links, (herein referred to collectively as Links) and a Folder Cloning process that utilises HardLinks or Symbolic Links. LSE, as its name implies is implemented as a Shell extension and is accessed from Windows Explorer, or similar file/folder managers. The extension allows the user to select one or many files or folders, then using the mouse, complete the creation of the required Links – HardLinks, Junctions or Symbolic Links or in the case of folders to create Clones consisting of Hard or Symbolic Links. LSE is supported on all Windows versions that support NTFS version 5.0 or later, including Windows XP-64 and the upcoming Vista operating system. HardLinks, Junctions and Symbolic Links are NOT supported on FAT file systems, and nor is the Cloning process supported on FAT file systems.”

  • 2006-11-19 3:46 am
    jasutton

    it wasn’t really “supported” by MS, but it was there. There’s a tool to create them out there too, although I’ve read it’s more of an OS hack than anything.

  • 2006-11-19 7:08 am
    StephenBeDoper

    Yay, finally an file/directory linking mechanism for Windows that *should* actually work from the command line level. Aka, no more stupid .lnk files.

  • 2006-11-19 7:49 am
    Brendan

    <joking>

    Just because Windows symlinks don’t work like Unix symlinks, doesn’t necessarily mean they weren’t meant to behave like they do in Vista. The real question is how long it will take before this new symlink behaviour is ported to Suse (inter-operability is important after all)…

    </joking>

  • 2006-11-19 10:39 am
    Havin_it

    I just hope Explorer will actually flag the symlinks/junctions/etc for what they are. I once inherited an XP system that was riddled with junction points, and it took a lot of confusion before I realised that’s what was going down. At least in Konqueror I can see exactly what is a symlink, and where it points to, in the tooltip.

    • 2006-11-19 4:31 pm
      n4cer

      I just hope Explorer will actually flag the symlinks/junctions/etc for what they are. I once inherited an XP system that was riddled with junction points, and it took a lot of confusion before I realised that’s what was going down. At least in Konqueror I can see exactly what is a symlink, and where it points to, in the tooltip.

      Vista’s Explorer shows links as shortcuts (i.e. the icon is overlaid with the little arrow). Theirs also a Link Target attribute you can enable that will give you the path to which the link points (if any).

  • 2006-11-19 5:35 pm
    dmitry

    Well, if Vista is able to follow the symlinks via network , it looks to me like a back door offered by MS itself…

    • 2006-11-19 8:29 pm
      n4cer

      By default, only Administrators are allowed to create symbolic links, and only local-to-local and local-to-remote links are allowed. So basically you’re limited to shortcuts to local resources and file shares (which is similar to what you have in previous versions of Windows). If you link to a share that is linked to another share, you will not be able to traverse that link by default.

      If you choose to trust a share, enable remote access, and/or to give users the ability to create symlinks, you should have some knowledge of the implications.

  • 2006-11-21 1:46 am
    malxau

    bio: I’m a regular osnews reader (though seldom make comments), and for the last little while I’ve been maintaining NTFS up here in Redmond.

    The article describes accurately how symlinks work in Vista, although it should be pointed out that this is completely by design.

    A junction is evaluated on the server. A symlink is evaluated on the client. At least as far as directories are concerned, Vista gives you the choice about which evaluation method you prefer. Unfortunately, there is no such thing as a file junction, so linking to files requires symbolic links.

    As other comments point out, the reason the user scenario works on Linux is because Samba etc. evaluate the symbolic link on the server so that an NT4 Windows client can “traverse” the link because it never really traverses anything. Samba turns client-evaluation into server-evaluation, which works pretty well, at least most of the time.

    Others here have commented that it’s unwise to have a link on a remote share that links to a local file. That is correct, and by default, Vista has policies that prevent evaluation of those links. However, it is configurable – you can have these links if you really want to, unwise or not.

    The design of symlinks was client-evaluation. Server-evaluation would have been a *lot* easier (and faster!) to do. This behavior will not change in a hotfix/qfe/service pack/fiji/anything else.

    Also, to be clear, we’ve been very consistent about NTFS – the on-disk NTFS format has not changed. The on-disk format is 3.1, which is the same as XP. This is important for compatibility. Symlinks are just reparse points. You could, given enough free time and a Win2k IFS kit, build your own Vista-Symlink-evaluator for Win2k. Similarly, Samba could be made to parse them, although there would be namespace translation issues (what’s C:fooar on Linux anyway?)

    The real prick with Vista Symlinks is (as others have pointed out) the requirement that, by default, only admins can create them. There are several compatibility/security reasons for this, which belong in a seperate discussion. Hopefully *that* can be fixed in future – but it won’t be until a future Windows release, at the earliest. You can change this behavior by giving other groups the right – mmc, local computer policy, computer configuration, windows settings, security settings, local policies, user rights assignment, create symbolic links.