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.
First, a correction. Symlinks haven’t really been added to Windows Vista. Sure, you can use the mklink command 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.
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 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.
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.
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 (and you can most certainly forget about your enterprise Linux install or grabbing shared & symlink’d media directories from your Mac either).
But it’s not all bad. The parts of Vista’s mklink command that do 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.
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 of your machines are on Vista too – at all times. And if you’re in a corporate setting? Don’t even think about it.
If you want more unix comparisons, see the excellent comments on OSNews for shell excerpts and more info.
What sort of bullshit article is this?
If your file driver doesn’t support symbolic links you want get symbolic links anyways.
If you want to see Vista symbolic links in XP figure out a way to update the file driver in XP
or write your own file driver using WDK.
This is the same with other operating systems. There are several file drivers which make a non-Windows filesystem look like fat but might support the foriegn filesystems specific features. But nobody call those foriegn filesystems features are ‘fake’.
What an idiotic reply, Anony. The point is that NTFS still doesn’t support symlinks. They’re fake symlinks simulated by Vista. You can’t “update the file driver” in XP and you can’t write your own file driver using WDK because the symlinks aren’t a part of the filesystem.
Right. Anony, consider the case of an NFS share of an ext3 partition exported by a Linux machine. Think about browsing it from Windows using Services For Unix. The symlinks work, because they’re implemented at the filesystem level on the NFS server. The reverse case with Vista as the server and a Linux machine as the client won’t work, because the symlinks are being faked at the OS level by Vista, not being truly implemented at the filesystem level in NTFS.
What a bullshit reply Anony.
How come it works with every other platform out there but Windows? How come the same situation played with role reversal and a unix machine works out perfectly for all parties involved? How come people like you make stupid comments without knowing what they’re talking about? And of course, are too scared to post with even a pseudonym because they know they’re talking bull.
Hi,
I just read the comments at OSnews and Neowin and want to point something out here at the main article.
Some people are quoting a Microsoft FAQ that mentions using the Group Policy Editor to enable symlinks in networked folders – however, the assumptions being made are incorrect.
The GPE enables symlinking on NFS for Vista clients only and does nothing to address the main issue here; which is that Vista doesn’t support symlinks on NFS for anything other than another Vista machine. Users of older Windows and other platforms will not be able to access Symlinks on network shares regardless of what settings you picked in the GPE.
That aside, it’s really sad that Microsoft would castrate the single most often delayed and most useful (for power-users obviously) feature in Vista, and I also hope that it gets implemented via a hotfix. It would really be a major disappointment to delay true Symlink support all the way till Vienna!
Thanks for bringing this to everyone’s attention!
This entire article is about one minor flaw in the Symlinks? What you’re saying, as far as I can ascertain is that the only functionality absent in this is the ability to set a symlink to a foreign host. OMFG! Let’s stop the Vista release! A seldom used ability from another OS isn’t present!
NTFS has had support for symlink type constructs for quite a while. Vista is the first time in a long time that a small extra piece of functionality has been made available, and additionally they’ve made some tools available to do this as part of the OS. Last time around the functionality was even less complete, and there were no tools, and you’re complaining?
Firstly, creating such a symlink is very problematic:
1) Access permissions – When are they set? When you create the link do you enter the credentials and cache them? If so, how do you keep them secure? Do you have users enter them when accessing a file – How can this be made obvious to the user (i.e. What password do I enter? It’s just a folder, right?)
2) Host accessibility – When large parts of your hard drive become inaccessible because you are not able to connect to the host you are symlinking too, will your programs fail?
Bear in mind also, that Windows Server has the ability to create distributed file systems through its Distribted File System / DFS feature, which provides the ability to coalesce files from hundreds of locations into one consistent UNC mapping. It’s all managed via WMI, MMC and the consistent management API’s which means for administrators who know that they’re doing, DFS is the path of least resistance for creating the kind of file system you’re griping about.
You’ve picked a minor nit, and you’ve made a big enough scene that Slashdot picked up on it. That means that you’re an idiot, and that Slashdot editors, yet-again, aren’t doing their due dilligance.
So what you basicly ment to say Steve. Is that while Linux and the rest of the *NIX based world has no problems with symlinks at all, in windows it is “problematic”?
I fail to see how sym links are a seldom used ability. My Linux desktop (Debian Sid) reports 31269 symlinks and my Mac OS X 10.4.8 iBook reports 11621. Thats a rather large number of ‘seldom used’ abilities. The Mac one is slightly off because HFS supports ‘aliases’ that are slightly better than symlinks in the fact that they can actively find ‘moved’ files (it stores not just a path but an ‘unique identity’ as well, this works as long as the file remains on the same volume, much like you can’t make hard links across volumes in Linux).
From what I can see it isn’t symlinking _to_ another host. It is the fact that the symlinks behave more like their Windows shortcut counter parts. Anything else that doesn’t support the specialized API cannot resolve the link, instead of every other system which implements it at the driver level.
To answer some questions, access permissions of a sym link are that of its target. Just as if I make a short cut in Windows to start an application that I don’t have the permission to, the application will refuse to start, the symlink operates on the same principle. Of course Windows shortcuts are an Explorer feature, not a file system level feature. It would also appear that the new symlink feature in Vista isn’t much better either.
And if I’m symlinking to a remote server and that server goes AWOL and I don’t have those files cached (at times 50% of my RAM is used on disk caching operations by Linux, a different design decision from Windows it seems. I had an example of where an IDE channel on a server died meaning that the primary hard drive was unavailable, including its swap partition. The box was still operating but when I went to start up a Java application on it, it failed. After a bit of investigation I saw that the thing was unable to access the hard drive. I logged into the box and shut it down as gracefully as you can. Until just before that point it was still acting as the primary proxy server), the answer is yes, programs will fail. But if I’m using Windows Folder Redirection (the closest thing available to symlinks I believe) to commonly share the program files of say Word, then its going to fail as well. No operating system can overcome losing its hard drive due to whatever reason (IDE channel failure or network server failure). If you rely on it and it dies, you’re not going to go far are you. But again, this isn’t about symlinking to other machines, its about accessing the symlinks from anything but a Vista box and realizing it doesn’t work because its not implemented at the file system/kernel driver level (its just an API stuck on the top of something else, again, Windows shortcuts).
DFS is aimed at providing something different, perhaps because you’ve never used symlinks you don’t realize what they do or how useful they really are at times. I work on some projects where I’m changing parts of a stable system. I use sym links to keep those changed parts in version control instead of committing the entire project as a branch. I only add the files I need or change, anything outside of that I can easily ignore. Until Windows gives me that sort of power, its pointless to me as a developer environment.
References
Apple Docs on HFS Aliases: http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/Aliases.html
It’s problematic because Windows wasn’t built with this in mind, where Linux and other products have but to copy the template set forth by Unix, with regard to filesystem conventions. The functionality that the author bleats on about here is achievable via the dedicated mechanism called Distributed File System, which lets one file-sharing server provide a structure that in reality is spread across multiple other machines.
Windows doesnt *need* symbolic links for any functionality in the OS, no applications out there *require* it and simply put, there isn’t a large groundswell of developers who need it either.
The author of this article has no awareness of Single Instance Storage (One machine with many links to one file), Distributed File System which can be combined to produce the required effect very readily by those who are familiar with Windows. There are windows-specific conventions to deal with. Windows isn’t Linux, it doesn’t need to mirror every piece of functionality, particularly one that isn’t used by most people. This, purely and simply is just a case of Linux users beating the drum when really it’s a case of two different OS’s built on different technologies doing similiar things in different ways.
Next on Neosmart, “Windows Not Based On X11, OMFG WOOT!!!11eleventyone”.
Steve Gray, you’re a dingwad. I don’t think you even know what symlinks are useful for. The article has nothing to do with symlinking to remote hosts at all.
He’s talking about files on a machine symlinked to other files on that same machine. If the symlink API was implemented in the FS layer as it should be, that would be perfectly transparent to ANYTHING that accesses the file or symlink.
According to the author, Vista’s implementation fails in several ways. If this symlink happens to be on located within a network share and another machine tries to access the file via the share, it will fail. If this file is in the web root directory, and a client browses to this file with his web browser, it will fail.
Pull your head out, take a remedial English course and read the next article a little more closely. And while you’re at it, look at your website in browsers besides IE every now and then and you won’t frighten off new clients.
Symlinks *are* implemented in the filesystem layer, as reparse points that are handled transparently in calls. Applications that open files referred to by symlinks will open the pointed-to file, unless they explicitly ask to open the Symlink/reparse point.
As for SMB support for those links, I refer you to the SMB2 specification, which clearly outlines that symbolic links are to be dealt with on the *client*. Thats not an issue with Vista, thats following the damn specification.
If the IIS issue he’s describing is genuine, despite the fact I’m unable to replicate it here with Vista RC2, then it sounds like a minor issue that needs fixing with a hotfix. Apart from that, I’ve got .NET programs reading and writing from symlinked files without incident.
As for your other gripes, try to stay on topic.
Someone else came along and actually spent the time to document that there is nothing wrong with the Vista implementation of Symbolic links:
http://www.osnews.com/permalink.php?news_id=16524&comment_id=183548
So not only do Microsoft follow the spec by not evaluating the Symlinks on the server-side by instead passing them to the client by default, but they also extend a branch to other users by providing support for evaluating over networks in four different ways, configurable via Group Policy.
If your buddy has the current working documents for your project symlinked on his workstation, especially if you are in an enterprise development environment, you, your buddy, and the project manager are idiots. That is why CVS systems exist. I’ve been using symlinks ever since they existed (old BSD and System III/V hand) and I’d never be stupid enough to use them in that manner. If you or the members of your team are this dim, there are over a dozen automatic folder-synching tools out there, any of them for free no less, for automagic synchronization to one or more repository networked folders. No networked symlink required. Serious engineering teams use serious tools. A document database and/or versioning system is a must.
This is a prime example of the misuse of symlinks that I’ve seen over the years serving additional duties as a SysOp/SysAdmin. There is a case to be made for using them to mask distribution, kernal & application versioning, and site specific implementation deviations and that is the limit I draw. I’ve had the capability here ever since it existed on the university & US Navy machines, and since the ’80’s on my personal computers (non-MS). Aside from the system defined symlinks, I’ve never created a single symlink or hardlink. I have had to deal with sites where such links were created and not documented either accurately or in a timely manner. Unmunging such a site is not a pleasant prospect. It is far easier to deal with shares, NAS, and FC/SAN-LUN’s any day of the week. Those you can enumerate and unmunge (correct) relatively quickly.
Steve Gray more than adequately addressed the real issue here. That non-Vista clients cannot resolve network symlinks as the *client* lacks the capability. If you want the capability (I do not), upgrade or switch to an OS that has it. More sound and fury signifying nothing. Ya’d think the three camps would have something better to do {sigh}.
Symlinks are a tool used to optimize file storage. If you need a directory full of files (symlinks to files), the symlinks allow you to avoid having multiple copies of the same file just because they have to exist in seperate directories. This is the most powerful use that I know of in the Unix world. IMHO, these should be inplemened at the file system level. The reason that things like this work so well in the networked unix environment, is that in Unix, the layers are well designed and the idea of the “unknown provider” is ubiquitous. This is why file descriptors can be opened on a file, a socket, a pipe… It is an elegant solution and Part of why I think so highly of Unix, and Sun’s NFS, and streams, and protocol stacks. These people at Microsoft should concentrate on stealing all of the good ideas, and not just a few. This situation about the symlinks is either a radically stupid accident, or a radically stupid policy decision. It s one or the other, and I don’t really care which, its stupid either way. They may chose not to fix it, and call it a feature. If DFS is there idea of converging disparate file systems, that’s typical in a world where they visualize the Microsoft Enterprise sitting on top of everthing else. Maybe I want unix on top and I want to map Windows file systems into my unix file system on a mount point.
LOL @ Steven.
You seriously have a problem reading. You link to a comment on OSnews, when the very comment above your first reply here specifically debunks that link.
The OSN comment simply says that Vista symlink access via NFS/UNC *can* be enabled or disabled by a system admin. It also says the *same exact thing* as the NST article: you *need to have* a VISTA client machine. You can choose to disable symlinks for *VISTA CLIENTS* but no matter what, you *CAN’T* enable Symlinks for non-Vista clients of a NFS share.
Learn to read and stop spewing pro-MS BS when you can’t even support it.
Read the other comments, and get real.
Steve Gray – Microsoft’s DFS/FRS is a fine technology for “coalesc[ing] files from hundreds of locations into one consistent UNC mapping”, it’s just that it only works if you sacrifice burnt offerings to the right gods under the correct moon phase while holding your mouth just right. In other words, you can take it and stick it up your bum. As for the assertion that it is the client program’s responsibility to know how to resolve a link created by the host OS (ring ring) – excuse me a minute – oh, the cluephone, it’s for you! Do we have to use different FTP clients to resolve symlinks on a UN*X-variant host? Different web browsers? In conclusion, you are an idiot whose opinion is worth nothing.
I don’t see how the post above debunks anything. The CIFS / SMB2 specification clearly outlines that the symlinks are supposed to be evaluated in the context of the client. Windows offers options to override that behavior in four ways, including server-side evaluation of symlinks through group policy, depending on the effect you’re trying to achieve. That older, pre-Vista Windows versions are ignorant of how to follow symbolic links does not mean that the feature itself as-implemented in Vista is incorrect.
As for the complaints about DFS / FRS, an ignorance of how to apply the technology does not mean the technology does not exist / work. I’ve deployed several applications that have used both extensively. An ignorance of how to apply them does not simply infer that the technologies do not work.
*swings his Wii controller around*
Steve: You are just equally and totally full of MS propaganda; you are a cog in their machinery.
What you’re saying *is* entirely right except that it takes only MS world into account. Like LT said, DFS may be a cool feature in itself but as long as you *NEED* to have a Windows machine with special capabilities also (i’m pretty sure stuff below NT 4 or possibly even 2K can’t handle it and i wouldn’t be surprised if it comes only with the “Server Editions”), it’s worth nothing to the rest of the world.
Well, LT already said it, so i get back to…
*swings his Wii controller*
Someone is trying to claim a flaw in Windows, one that I personally feel is an overblown mis-understanding on the part of those claiming it. As for proposing a Windows-based solution to a supposedly Windows-based problem, that seems the natural order of things, surely. If this was a gripe about Linux standards implementations, would it be even remotely appropriate to blindside the argument with ‘Oh well, MacOS does it better!’. Of course not. Thats why I recommended Windows-based solutions to this Windows-based ‘problem’.
Windows Vista supports a new feature, some older versions don’t, and there are ways to provide downlevel support in various capacities without scrapping an entire existing infrastructure.
But what about Linux? The last time I checked, Ubuntu users couldn’t receive a hotfix for Vista symlink capability via Windows Update…
I think the reason why so many people (including me) are making a big deal of this, is because we are tired of the Microsoft way of doings things. They take some neat feature that has been perfected by years of experience in *NIX, and then implement in windows. But always with a friendly twist so that lo and behold it only really works if you are using windows server and client. (And the latest version of those thank you very much…)
Exactly Robert! It’s kinda like the “Last straw that broke the camels back.”
As someone on /. said, if this is the only thing wrong with Vista, then Microsoft has won.
But unfortunately, this isn’t the only thing, it’s simply more of the same, age-old bullshit.
But you know what (sorry to post again, can’t seem to ‘edit’ my previous post?), Windows is still a better OS. That’s why the majority here are pissed. Because they’re going to be using it, but this feature and many others are borked/broken/incomplete… if you get what I mean.
I’ve never used Linux before, but I just looked up symlinks on Wikipedia and Google (all of them linking back to NeoSmart – you guys are everywhere!) and IMO Microsoft was wrong. I still love Vista, it’s absoloutely the very best OS out there, but if Microsoft creates a standard (SMB protocol) that Linux can adhere to, why can’t MS stick to it?
I thought it was simply that this kind of technology can’t be backported to older/other OSes, but reading through all the comments here, on Slashdot, and OSnews, it looks like Linux can create SMB-compliant symlinks too, with the exact same functionality as Vista’s symlinks, and have them work with older OSes…. Something smells fishy here!
Oh, and I don’t know what you’re talking about Frohman, NeoSmart’s CMS accepts my < and > and ! & these tags perfectly (without using HTML encoding and entering them as-is).
No, Frohman is right (damn, I love this new editor!),
It didn’t use to work, I just rewrote the entire thing, it’s now WYSIWYG with a nice AJAX HTML viewer to show you what your code is – no nasty pop-up windows.
I’ve modified your post Frohman, fixed all that incorrect encoding up. Sorry!
mklink is available for Windows XP too.
http://www.zdnet.de/builder/program/0,39023551,39149226,00.htm
It’s an official release from Microsoft, and I don’t read German 🙁
I’m not sure if this is a custom-backport of mklink to Windows XP or if it’s the actual Vista Binary, but here’s a direct URI in either case… I’ll check and post back soon:
ZDNet’s mklink for Windows XP 1.0
Hehehe, *nix lovers are hilarious. Thanks for cheering me up this cold monday morning.
What’s the problem anyway? Those who want server-side link resolution and support for pre-Vista clients are free to use junctions and hard links instead of symbolic links!
To Steve Gray. Point is it sounds like a hack – symlinks should implemented in the file system driver (as in *nix) and it sounds like it was hacked into the OS (kernel) somewhere else in typical Microsoft style. (Perhaps so they could put another “feature” onto the Window Vista Shrinkwrap Box to justify the spin to their customers that they should upgrade.) Likewise they probably deliberately didn’t put the feature into the original NTFS design (and drivers) so as not to been seen copying leading alternative operating systems. FINIS.
What else would anyone really expect form Microsoft!?
> symlinks should implemented in the file system driver (as in *nix)
There is a lot of confusion and misunderstanding in this thread. I’ll try and summarize the real state of Vista symlinks.
First, the basics:
Why do symlinks only work Vista to Vista ?
Because symlinks are client evaulated, the client’s OS must be updated to understand them. Since the changes required are extensive (kernel, IOManager, FS utilities, explorer shell, apps, Win32 APIs…) it is highly unlikely that any Windows prior to Vista will ever be made symlink aware. Therefore there was no real point in exposing them through the SMB-1 protocol, since all Vista machines will negotiate SMB-2 to communicate.
Why don’t they work with *nix clients:?
There are two parts to this, depending on the protocol you are talking about:
Hope this helps clarify things.