I’m sorry, you don’t have permission to know where this shortcut file should show up in the Explorer window


Commenter Gabe suggested that the shortcut file should contain a bit that indicates whether the target of the shortcut is a folder, so that shortcuts to folders can sort with real folders. "That would allow them to sort properly without doing any additional work beyond that required to see its icon." (Commenter Josh agreed that "The performance reason doesn't really apply here, since explorer is already looking at the target to get the icon," rejecting commenter AndyC's argument that performance may have been a concern.)

Well, first of all, shortcuts do remember whether the target is a file or a folder, or at least whether it was a file or folder at the time the shortcut was created: IShellLink::GetIDList + IShellFolder::GetAttributesOf tells you this and more about the shortcut target.

But saying that this isn't more work than what's necessary to see the icon misses a few points about file icons: First, you can't sort by icon, so the consequences of getting the wrong icon (or never getting the icon at all) are purely visual. What? Never getting the icon at all? Well, yes, if the file has been archived to tape, Explorer won't bother recalling the file just to get its icon and will instead just use its generic type icon, or if there is no generic type icon, a generic document icon. After all, you don't want viewing a folder in Explorer to recall all the files from tape. That sort of defeats the purpose of archiving the files to tape.

Even if Explorer decides to get the icon, it performs that operation at low priority and in the background. By comparison, you don't want to decide where the item should appear in the list as a low priority background task. If you do, then you either show nothing until all the sort information is ready (in other words, show nothing for a very long time, possibly forever if the file has been archived to tape), or you show everything, but move items around as better information arrives. Neither is a particularly pleasant experience for the user.

What's more, it means that where an item sorts depends on who asks. If you don't have read permission on the shortcut file, then you don't have enough permission to find out whether it's a shortcut to a folder or not, and then Explorer has to decide where "don't know" files go. Do they go with the non-folders by default? Do you create a third "don't know" category? No matter what you choose, the result is that the location of the file changes depending on who asks. "Hey, where did that shortcut file go? Oh, there it is. What's it doing over there? Computers are so hard to use."

Commenter Leo Davidson noted that determining whether the target of a shortcut is a file or folder is cheap if the target is a local hard drive that is not spun down, but that's an awful lot of ifs. Does this mean that you sort shortcuts to local hard drives that are not spun down differently from shortcuts to network drives or shortcuts to drives that are spun down? Won't users find this confusing? "Hey, where did that shortcut file go? Oh, there it is. What's it doing over there? Why does this shortcut file show up half of the time in one location and half of the time in that other location? Computers are so hard to use."

Now, even if it's a shortcut and the target is on a local hard drive that has not spun down, that still doesn't mean that you can determine whether or not it is a file or a folder: The target may no longer exist. The act of resolving a broken shortcut is deferred until shortcut is launched, a form of lazy evaluation which avoids having to undertake an expensive search operation until the result is actually needed. If you want to sort shortcuts based on the attributes of the target, you'd have to resolve all the broken shortcuts to see where the target moved to and whether it's a file or a folder.

Now, you might decide that broken shortcuts are already broken, so who cares what happens? But there are scenarios where almost all shortcuts are broken and the user relies on the resolution process to fix them up. But you knew this already. If the Start menu profile roams from one machine to another, the shortcuts are all broken, but when the user decides to launch the shortcut, the resolution process patches them up so they launch the correct program; it just takes a little longer the first time.

I suspect that when Leo Davidson runs the program which sorts shortcuts to folders along with the folders and includes the shortcut target in the column description with "no noticeable effect on performance", he doesn't try running it against a server halfway around the world with a 500ms ping time. If you have a folder with 100 shortcuts over a network with 500ms latency, it'll take you nearly a minute just to sort the items. It'll be even worse if you have a folder full of files which have been archived to tape. Maybe that scenario isn't important to him, but it's important to a lot of people. In fact, one might say that the Explorer folks don't pay enough attention to these scenarios, because at every release of Windows, you can count on those people submitting streams of complaints that the most recent version of Explorer sucks even more on their international corporate network, and then the Explorer team has to do a little redesign work to get things to suck less.

Comments (26)
  1. Alexandre Grigoriev says:

    Forget about offline files on tapes. I really suspect this feature was not used in more than a couple deployments. I suspect it’s still being used by blogs.msdn.com, though. This is where it seems to keep its databases.

    Windows 7 is phasing out tape support. Ther is no offline file support anymore in Win2008 R2.

    Windows 9x used to have shelliconcache file to avoid reading icons all the time. Unfortunately, it was implemented very poorly and was getting corrupted very often. Mutexes, anyone?

  2. Nawak says:

    The second paragraph says that shortcuts remember whether the target is a file or a folder, so Explorer really could sort based on this information.

    All the remaining of the post seems to address the comparison with icons and the fetching of a unstored information, which, while interesting, was not the original question…

    Only the bit about the rights to read the shortcut to get the isFolder bit would be relevant to the original question. But it’s a problem coming from the implementation of links as regular files read by explorer instead of files interpreted by the filesystem. Being regular files and being on an ACL-able filesystem, the abstraction of representing the linked object as the object has to break somewhere. And it breaks because Explorer is subject to ACL (whereas a kernel implementation wouldn’t).

    (Sorry if that’s a multiple post, I couldn’t tell whether the last submits worked)

    [“…so Explorer really could sort based on this information”: Please re-read paragraph 4. Consider the case where you’re viewing a folder on a server halfway around the world with a 500ms ping time. And shortcuts are files (as opposed to file system “special objects”) for reasons I explained some years ago. And using kernel to bypass the ACL means that you are asking for a security vulnerability as a feature. -Raymond]
  3. nathan_works says:

    Files on a network with 500ms access time.. The bane of my current existence.. I can’t blame MSFT for crappy networks..

    I still dislike the "system freeze" while explorer tries to probe the network drive whenever it opens..  And worse when some logon script maps one of those drives. I got tricky to fix that via the .hosts file.

  4. Nawak says:

    When I said that kernel could bypass ACL, I was talking about the filesystem code residing in kernel space, which reads the NTFS partition as raw data and present it as a generic filesystem entity to the kernel. It wasn’t really a bypass but a part of its normal operation with another property to report to the generic filesystem layer. I did not intend to make the kernel operate on files/links when ACLs say it shouldn’t, I wanted to compare two implementations of links, a user-one and a kernel-one.

    About the remote folder, of course if the query for the isFolderBit makes a round trip each time, then it will be problematic. But not knowing the protocol used when mounting a disk, I assumed this info could be sent alongside the dates, sizes & co, and then it would be the local network driver that would really be queried by the IShell interface.

    I didn’t realise that this method also required the links to be real filesystem objects.

    My post was only to give another point of view of the problem which, for me, really boils down to “Shortcuts are sorted with files because they are files and presenting meta-information about the linked object need read rights on the links, rights which are not always available”

    I may be mistaken but if that specific implementation went away, all other problems would disappear as well, that’s why I chose to identify it as the root cause.

    Of course, the requirements you listed in your old article forbid another implementation anyway.

    [If kernel also respects the ACL, then what’s the point? Both user mode and kernel mode respect the ACL, so moving the call to kernel mode doesn’t change anything. Oh, and we saw what happens if you decide to modify a file system enumeration function to return more information than it did before. -Raymond]
  5. Gabe says:

    Why not make the directory bit part of the filename, then? Use .lnk for a link to a file and .lnf to a link to a folder.

    Of course there would be no easy way to enforce that the .lnf files really point to folders and such, but it would be useful for sorting — just like how .scr files are really just regular EXEs with a different extension to allow the screensaver dialog to find them.

    [If you change a shortcut’s properties, does that mean the file has to be renamed? And why should the code that creates a shortcut care about what file extension it needs to put on the file? (And what about shortcuts that aren’t saved in files at all?) -Raymond]
  6. Leo Davidson says:

    You’re right, I rarely encounter shortcuts pointing at slow network drives. If I did I’d probably turn the option off in the program I use. (FWIW, the option is off by default.)

    It’s one of those options which is really great for 99% of people and terrible for 1%.

    (Whether that sort of option/feature makes sense for Explorer is another thing. Perhaps not. The program I’m using, though… well the reason for using it is all options and things it does that Explorer doesn’t do.)

    The program I use can also displays a column showing the target of each shortcut (or NTFS link, etc.) which I find very handy. Even though that is calculated on a background thread (like the icons) I still turn that particular column off (or rather don’t turn on) for network drives. That’s more because of the other (more network-demanding) things that populate the same column than the shortcuts themselves.

  7. Nawak says:

    I see that we are not understanding each other Raymond…

    I’ll try one last time but if we still don’t manage to do it, I’ll give up as it wasn’t really that important.

    As a user-mode application, explorer is limited by the ACL on a file (enforced by the kernel, more precisely the generic filesystem code) and therefore cannot read links if the ACL do not permit it.

    In the kernel, the filesystem does not check the ACL of the items in a directory before returning meta-information about these items. It’s not part of the normal operation of listing a directory’s content. On my machine I can know the modification time of a folder/file for which the administrator has denied me of every rights. A kernel mode implementation of links could add another property to filesystem object (or another subtype) such as link-to-file or link-to-directory. I didn’t say it would be a good idea btw, just that as a kernel mode code, this new property could live without ACL restrictions like isfile/dir, dates and sizes are now. (The term “bypass” was wrong of course, sometimes I struggle with words…)

    Way to digress on a side remark :)

    [Promoting the value into metadata (that has weaker ACLs) creates other issues: How do you keep the metadata in sync with the shortcut file? Do you trust the application that created the shortcut to set the metadata attribute correctly? What are the consequences of being lied to? Do you have a potential security hole where a bad file can sneak through because the security layer checks one flag while the execution engine checks the other? And (of course) how do you get all file system providers to support your new metadata? -Raymond]
  8. nah says:

    > On my machine I can know the modification time of a folder/file for which the administrator has denied me of every rights.

    Because you have rights for the parent folder, and that information is stored there.

    No magic to see.

  9. Rob Green says:

    [If kernel also respects the ACL, then what’s the point? Both user mode and kernel mode respect the ACL, so moving the call to kernel mode doesn’t change anything. Oh, and we saw what happens if you decide to modify a file system enumeration function to return more information than it did before. -Raymond]

    What was the actual outcome that Vista did?

  10. W says:

    Aren’t links to folders already folders containing a link on WinXP?

    Another solution would be simply using a different fileextension.

    Both solutions can solve the ordering problem. And both have the same disadvantage: links to folders and normal links have a completely different type.

    But I’m not sure if that different ordering is actually desireable. Links are already problematic from a security point of view, and this one might make it even worse.

    And it might be yet another leaky abstraction. And IMO the recent versions of windows already have too many of these .

    [“Aren’t links to folders already folders containing a link on WinXP?” Um, no, they’re just .lnk files. Try it. You’re thinking of shell junction points. -Ryamond]
  11. Ry Jones says:

    This reminds me of The Website is Down, http://www.thewebsiteisdown.com/, and the plugin it inspired (that I can’t link to or my comment gets blocked) at arrange by pen is dot com.

  12. Leo Davidson says:

    Thinking some more about this:

    Why would someone have a shortcut to a drive that was so slow that just checking whether one item is a file or a folder takes an irritating amount of time?

    If accessing the folder is that painful then it’s presumably a folder you would avoid accessing wherever possible and thus not something you’d be likely to want a shortcut to in a folder you did visit frequently.

    Similarly, I don’t see many people creating shortcuts to folders on CD drives, except for brief periods where they’re using the drives (and where the OS should be able to cache the folder information like it should cache the drive’s icon.

    So IMO we’re comparing the theoretical irritation of close to zero people (who create shortcuts to slow things) with the actual irritation of at least some people (who want shortcuts to folders to sort with folders).

    If the first group is non-empty then I imagine they’d be happy enough if the Shell simply avoided the check with network/removable drives and sorted those shortcuts as it does now.

    That’s my take on it, anyway.

    [It’s common to have shortcuts to slow media: “My Network Places”. But that’s not the point here. The issue isn’t a shortcut to slow media; it’s a shortcut on slow media. Consider opening \remoteserverstandardresources which is filled with shortcuts to all the documents, applications, etc. that your employees need to use. You don’t want to have to wait 30 minutes for this folder to open. -Raymond]
  13. Shog9 says:

    Wow… To everyone suggestion increasingly more complex / fragile ways to implement this: apart from a few Start menu links and that weird thing in Network Places, who uses shortcuts for folders? They don’t work like symlinks unless programs (like Explorer) go out of their way to handle them, and even then it’s not quite right. Whereas, hard links (reparse points) have been supported since Win2k, and with Vista you can even have real symlinks that *still* don’t require applications to do anything special under normal conditions.

    Why go to *any* effort to pile any more functionality onto a little hack introduced a decade and a half ago for the shell? Use the features built in to the file system, watch how everything works properly, get on with your life.

  14. Leo Davidson says:

    Shog9, until Vista using hardlinks was asking to accidentally delete half your data. The Shell didn’t know a junction/link from a real folder and deleting either would delete the contents of both (instead of removing the junction/link or asking what you want to do). Vista’s shell improved things there, probably because Vista is the first version of Windows to use junctions/links in places users actually see.

    You couldn’t use junctions/links in some situations with network drives until Vista’s softlinks were added, either.

    Junctions/links don’t work on FAT.

    Junctions will still cause problems with some tools which don’t understand them and have unintended behaviour when they encounter them. (OTOH, with a shortcut an application either sees it as a simple file or it has been explicitly coded to handle shortcuts and should do the right thing.)

    If all you want is something you can double-click on in one place and be taken to another place, why *not* use a shortcut? (Except for the fact it ends up sorted with the files. :) ) We’re not talking about something you can use as the input path to a command-line program — obviously junctions/links are better for that — we’re just talking about a shortcut for the user when they are browsing.

    I don’t have thousands of folder shortcuts but I do have a few in certain places and they’re very handy for jumping between related folders. They’re much easier to create and delete, and less risk to have around, than junctions/links.

  15. Jonathan says:

    I use shortcuts to slow media: I have a home computer and a laptop. The laptop has a shortcut to \homecomputershare so I access stuff from there. When I had XP on the (previous) laptop, I had the shortcut on the desktop. But then, every time I’d place a JPG there and try to view it, Explorer would try to enumerate all shortcuts and hang until resolved. I had to move the shortcut into a folder to avoid that.

    As for implementation: I’m surprised no-one suggested adding a bit in the .lnk itself of whether it links to a folder or file. That way retrieving the data would not incur any performance penalty. Of course, there’s the problem of what happened if a file turns into a folder, but I can’t think of any realistic situation where that happens.

    But I also think that the whole thing is not important enough to invest engineering time in.

    [See paragraph 2. Shortcuts do have a bit that say whether the target is a folder or a file. But in order to get it, you have to open the file and read its contents. Opening files and reading their contents is expensive. -Raymond]
  16. Gabe says:

    "[If you change a shortcut’s properties, does that mean the file has to be renamed? And why should the code that creates a shortcut care about what file extension it needs to put on the file? (And what about shortcuts that aren’t saved in files at all?) -Raymond]"

    I would bet that it’s rare that somebody would change a shortcut to a file to a folder or vice-versa. Should that happen, the only problem is that it gets sorted wrong.

    Obviously some code cares enough to generate the .lnk extension. Although it might be a bit more work, it wouldn’t have been that much more had it been the standard fom the beginning.

    And of course shortcuts that aren’t saved in files don’t have filenames. Hopefully whatever mechanism keeps track of them could somehow also keep track of whether they’re a folder proxy.

  17. djeidot says:

    I also can’t see what’s the big deal with this. It’s just a bit that you set or unset (or a filename extension change). You don’t have to sync the shortcut with the target. You don’t have to worry about ACL. You just set the bit when you create the shortcut and you’re done.

    It is only for sorting purposes, after all (isn’t it?)

    You worry about assuring that the shortcut is always “right” in terms of determining if the target is a file or folder. But you also talk about broken shortcuts, or shortcuts with the wrong icon, and I don’t see you worried about that. What’s the difference?

    Just as you do with broken shortcuts or wrong icons, when the user launches the shortcut you simply update the file/folder bit.

    [The difference is that under the current model, a broken shortcut still sorts in the same location after you fix it. This is important when you have common scenarios where shortcuts spend a lot of their time broken (see paragraph 8). As for “It’s only for sorting purposes after all”, imagine if you couldn’t find something because it got sorted in the wrong place. -Raymond]
  18. Leo Davidson says:

    [It’s common to have shortcuts to slow media: “My Network Places”. But that’s not the point here. The issue isn’t a shortcut to slow media; it’s a shortcut on slow media. Consider opening \remoteserverstandardresources which is filled with shortcuts to all the documents, applications, etc. that your employees need to use. You don’t want to have to wait 30 minutes for this folder to open. -Raymond]

    If it takes 30 minutes to open that folder when doing one extra GetFileAttributes, plus a ~1KB file read, per shortcut then I’d wager it already take 10-20 minutes to open the same folder under the current system. That use-case is already broken & unlikely to be used in the real world and it doesn’t seem worth making compromises over it.

    If it is a real issue you could always disable the sorting for shortcuts on or pointing to network folders. Maybe it’s better to sort them wrong all the time, though. IMO the pathological cases are unlikely to exist in the first place, though.

    [Consider a server with a 500ms ping and a directory with 1200 shortcuts. Enumerating the contents of the directory takes 7 seconds (open + 12 enumerations + close). Opening each shortcut to see whether it points to a file or folder takes 30 minutes (1200 * (open + read + close)). If you think this is an unlikely scenario, you need to spend more time on global corporate networks. -Raymond]
  19. Neil says:

    This explains why I always create Folder Shortcuts (which consist of a folder, desktop.ini and target.lnk) when I want a shortcut to a folder. You can expand them in Explorer view as if they were a real folder. I can never remember how to create them though.

  20. Jason Haley says:

    Interesting Finds: May 29, 2009

  21. Random User 43759 says:

    @Rob Green

    Looks like, "…the solution that was settled on was simply to stop using ‘fast mode’ queries for anything other than local devices."

    http://blogs.msdn.com/oldnewthing/archive/2007/02/01/1573160.aspx

  22. James Schend says:

    You see these kind of comments a lot on Slashdot, too– it’s really sad (to me) how many programmers, Windows or Linux, really have absolutely no experience with network administration on large networks.

  23. Leo Davidson says:

    “Consider a server with a 500ms ping and a directory with 1200 shortcuts. Enumerating the contents of the directory takes 7 seconds”

    Fair point, I was assuming Explorer would be getting back more information per file that just what the enum returns, but that’s probably not true as the enum struct contains the data commonly shown in Explorer. The enum avoids much of the round-trip overheads and doesn’t impose per-file overheads which are costly on a high latency network.

    However, I have spent many years with global corporate networks and the main thing I remember is that people avoid using any drive which is that slow *at all*, except when they really have to share data with people in other locations. Everywhere I’ve worked, people have had local drives (or ones on a fast network; e.g. London <-> New York) for day-to-day use and only used the slow ones when they really had to. The slow network drives are *already* basically unusable for most tasks.

    So I still feel that the pathological case is incredibly unlikely. Why would someone create 1200 shortcuts on a server that slow? Perhaps someone who it wasn’t slow for, but after creating them, if it caused problems, they could just delete them. They’re a nice-to-have not a necessity. Of course, so is the sorting option I advocate. If the argument is that it’s better to avoid causing a problem to people in a situation, however unlikely, rather than to provide a nice-to-have option to a few other people, then fair enough.

    You could still disable the functionality for shortcuts on, or pointing to, network paths. Perhaps you wouldn’t want them to be sorted differently depending on device type, but it wouldn’t bother me as a trade-off.

    Or you could cache the “is a directory” flag in the shortcuts (which would almost always be correct and when wrong the mis-sorting would be no more wrong, misleading or problematic than the other cached or background-populated information being wrong for a shortcut).

    [The folder isn’t slow – it comes up in 7 seconds. (And there are some companies which disallow access to local drives; you are forced to use the network. Because network drives are backed up and have security auditing.) And as I noted in paragraph 2, the “is a folder” bit is already cached in the shortcut. The cost is reading the shortcut. Mis-sorting is far worse than stale background information. If an item is mis-sorted you can’t find it. -Raymond]
  24. Leo Davidson says:

    "The folder isn’t slow – it comes up in 7 seconds."

    Seven seconds isn’t what I’d call fast. Faster than 30 seconds, sure, but still slow.

    The network drive is slow or else it wouldn’t have come up in this discussion.

    Maybe it could be considered "not so slow it’s unusable" if the only thing people ever do to the drive is read directory listings off of it and read/write individual files once or twice a day. I’d still call that slow, and something people would avoid, and certainly not something any sane company would make people use for their intraday work files.

    "And there are some companies which disallow access to local drives; you are forced to use the network."

    I’m well aware of that, but I can’t imagine any companies would force you to use a network drive which was so slow that reading 1KB files was an issue. People are given fast/local network drives to store their things because they simply cannot work properly if their files are stored on a drive which is so slow that every file read takes seconds.

    In my experience (~10 years working for global investment banks), slow network drives are only used for sharing data between locations, not for any individual’s personal work area. Where collaboration is required people work on things on a more local server and then copy the results to the distant server.

    More to the point, I cannot imagine anyone putting 1200 shortcuts into a *flat* folder structure. In the unlikely event that someone did, they’d see the problem even on a fairly fast network drive (or they’d get complaints from a remote office about how long that folder took to read) and they’d then do the obvious thing and organise the shortcuts into a tree structure. Which any sane person would do anyway as having to find things within 1200 shortcuts is no shortcut at all.

    "Mis-sorting is far worse than stale background information. If an item is mis-sorted you can’t find it."

    It’s just a broken shortcut at that stage. Hardly the end of the world. People have been dealing with them — ones whose target doesn’t even exist anymore — since Win95.

    Honestly, if feels like you’ve chosen a position — keep the status quo — and are looking for reasons to back it up. Easy thing to fall into, and I do it frequently myself.

    Proposed ideas need to be challenged, for sure, but you seem to be concentrating on the "why can’t we do this?" rather than the "how can we do this?" That’s fine if the feature is impossible to implement well, but your arguments against it seem to require unrealistic, pathological cases which are already stupid things to do now, like creating 1200 shortcuts in one place on a slow network drive.

  25. Anonymuos says:

    One might say that the Explorer folks don’t pay enough attention to these scenarios, because at every release of Windows, you can count on those people submitting streams of complaints that the most recent version of Explorer sucks even more on their international corporate network, and then the Explorer team has to do a little redesign work to get things to suck less.

    That’s the truth, nothing but the real bare truth. Explorer is a disaster than have made Vista and Windows 7 a disaster.

Comments are closed.

Skip to main content