{"id":285,"date":"2006-11-18T21:18:02","date_gmt":"2006-11-18T21:18:02","guid":{"rendered":"http:\/\/neosmart.net\/blog\/archives\/285"},"modified":"2013-08-26T18:13:16","modified_gmt":"2013-08-26T23:13:16","slug":"vista-symlinks-revisited","status":"publish","type":"post","link":"https:\/\/neosmart.net\/blog\/vista-symlinks-revisited\/","title":{"rendered":"Vista Symlinks Revisited…"},"content":{"rendered":"

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<\/a>. Just a couple of days ago, symlinks were our “big Vista feature of the week,” but now, we’re not so sure. <\/p>\n

First, a correction. Symlinks haven’t really<\/em> been added to Windows Vista. Sure, you can use the mklink command<\/a> to get Vista to intercept calls made to certain paths and have them silently and invisibly replaced with whatever real paths you previously specified, just like Symlinks are supposed to be – but that’s about it. Vista’s symlinks aren’t much better than junctions in 2k\/XP that don’t take up extra hard drive space, and indeed are quite a bit less compatible. <\/p>\n

<\/p>\n

It seems that the only calls to the symlink API Windows Vista occur during the creation of such files or when accessing them from Windows Explorer. No problems there. But the problem is, nowhere in Vista does there exist code for intercepting <\/em>these symlinks from foreign calls. 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. <\/p>\n

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. <\/p>\n

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<\/em> XP workstation (and you can most certainly forget about your enterprise Linux install or grabbing shared & symlink’d media directories from your Mac either). <\/p>\n

But it’s not all bad. The parts of Vista’s mklink command that do<\/em> work are excellent, as we’d expect them to be. One workaround for now is to create symlinks on Vista that point to XP\/2k3 folders on the same PC – for instance, linking the Mozilla user directory on Vista to a physical path on your XP partition. However, this doesn’t help when UNC paths enter the discussion – there’s simply no workaround for that. 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.<\/p>\n

In short, Vista’s symlinks don’t really exist. They pretend to be there for the user of the local machine (not to say that isn’t useful, because it really is), and if another Vista PC out there somewhere supports the proprietary symlink code used, it’s capable of accessing it too; but no more than that. If you plan on using Vista’s symlink features, you better be damn-well certain that all<\/em> of your machines are on Vista too – at all times. And if you’re in a corporate setting? Don’t even think about it.<\/p>\n

If you want more unix comparisons, see the excellent comments on OSNews<\/a> for shell excerpts and more info.<\/small><\/p>\n","protected":false},"excerpt":{"rendered":"

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 … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[127,53],"class_list":["post-285","post","type-post","status-publish","format-standard","hentry","category-software","tag-symlinks","tag-vista"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4xDa-4B","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/285","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/comments?post=285"}],"version-history":[{"count":2,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/285\/revisions"}],"predecessor-version":[{"id":2167,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/285\/revisions\/2167"}],"wp:attachment":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/media?parent=285"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/categories?post=285"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/tags?post=285"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}