• The Old New Thing

    Why doesn't the Low Disk Space warning balloon show up as soon as I run low on disk space


    A customer reported an issue with the title "The notification balloon for Low Disk Space does not appear even if the free disk is very low." They provided the following steps:

    • Install Windows 7 64-bit on a SATA drive.
    • Copy files to the system drive until disk space becomes low.
    • Observe that the notification balloon for Low Disk Space does not immediately appear.
    • The balloon appears approximately ten minutes later.

    You read through the steps nodding, "uh huh, uh huh", and then you get to the last step and you say, "Wait a second, the subject of your report was that the balloon doesn't appear at all, and now you're saying that it appears after ten minutes. So it does appear after all. What is the problem?"

    The customer explained that on earlier versions of Windows, the Low Disk Space warning balloon appeared within one minute, whereas in Windows 7 it can take up to ten minutes for the balloon to appear.

    Yup, that's right.

    In previous versions of Windows, Explorer checked for low disk space once a minute. The Windows performance folks requested that the shell reduce the frequency of checks to improve overall system performance, and the shell team agreed to reduce the frequency to once every ten minutes. (The performance team made other suggestions to reduce the impact of that code that runs every ten minutes.)

    So yes, in Windows 7, it may take up to ten minutes for Explorer to report that you are low on disk space. But Explorer never promised that those reports would be timely. Or that they would even appear in the first place. The behavior is not contractual; it's just a courtesy notification.

    Related: How full does a hard drive have to get before Explorer will start getting concerned? and How do I disable the low disk space notifications?

  • The Old New Thing

    What are the recommended locations for storing different types of files?


    Some time back, I provided informal guidance regarding what types of files go into which folders. Here are the official guidelines [pdf], for those looking for something with more authority than just me blathering.

  • The Old New Thing

    How does Explorer determine the delay between clicking on an item and initiating an edit?


    Ian Boyd wants to know why the specific value of 500ms was chosen as the edit delay in Windows Explorer.

    Because it's your double-click time.

    Since the double-click action (execute) is not an extension of the single-click action (edit), Explorer (and more generally, list view) waits for the double-click timeout before entering edit mode so it can tell whether that first click was really a single-click on its own or a single-click on the way to a double-click.

    If the timeout were shorter than the double-click time, then double-clicking an item would end up having the first click trigger edit mode and the second click selecting text inside the editor.

    (If the timeout were longer, then everything would still work, but you would just have to wait longer.)

    Ian says, "Through my testing it does not appear linked to configurable double-click timeout." My guess is that Ian changed the double-click timeout not by calling Set­Double­Click­Time but by whacking a registry value directly. The values in the registry are loaded and cached at logon; you can update them all you want at runtime, nobody will care.

  • The Old New Thing

    Why don't all of my folder customizations roam with my profile?


    A customer reported some inconsistency in how folder customizations are handled by roaming profiles.

    1. Log onto Server1 with a roaming profile.
    2. Open the following folders and in each one, customize the icon size:
      1. Library\Documents
      2. \\server\share
      3. C:\Temp
    3. Log off from Server1.
    4. Log onto Server2 with the same roaming profile.
    5. Open the same folders and observe:
      1. Library\Documents: Icon size roams.
      2. \\server\share: Icon size roams.
      3. C:\Temp: Icon size does not roam.

    Why doesn't the C:\Temp customization roam?

    Well, if you think about it, it makes sense that the setting for C:\Temp doesn't roam because C:\Temp doesn't roam either! The C:\Temp on Server1 is not the same directory as the C:\Temp on Server2.

    Let's change Step 2 slightly:

    1. Log onto Server1 with a roaming profile.
    2. Open the following folders and in each one, create a file called TEST.
      1. Library\Documents
      2. \\server\share
      3. C:\Temp
    3. Log off from Server1.
    4. Log onto Server2 with the same roaming profile.
    5. Open the same folders and observe:
      1. Library\Documents: TEST is there.
      2. \\server\share: TEST is there.
      3. C:\Temp: TEST is missing.

    I think nobody would be surprised at the results of this second experiment. The changes to Library\Documents are there because that folder is part of your roaming profile. The changes to \\server\share are there because it is a global resource. And the changes to C:\Temp are not there because the first one is "C:\Temp on Server1" and the second is "C:\Temp on Server2".

    The shell saves icon size customizations in folders differently based on whether it is a global resource (like a network share) or a local resource (available only on the local machine). Settings for local resources do not roam because, well, they're local and have no meaning when roamed to another computer.

    The Documents case manages to get the desired effect, but by different means: Settings for libraries are based on how you customized the view via things like the "Arrange by" menu. Those customizations are saved in your roaming profile, and they therefore roam with you.

  • The Old New Thing

    Sure, we do that: Context menu edition


    A customer reported a problem that occurred only when they installed a particular application. If they uninstalled it, then the problem went away. After installing the application, the "Run As" context menu option stopped working. The customer didn't provide any other details, but we were able to make an educated guess as to what was going on.

    A common programming error in context menu extensions occurs in extensions which add only one menu item. These extensions ignore the parameters to the IContextMenu::InvokeCommand and simply assume that the only reason the method can be called is if the user selected their menu item. After all, if you have only one invokable item, there's no need to figure out which one the user selected, because you have only one to begin with!

    The problem is that a context menu extension can be invoked not because the user selected an item under its control but because a verb is being invoked programmatically, and each handler is being asked, "Do you know how to do this?"

    The result is that the context menu host calls the extension to say, "If you know how to do runas, then please do so," and the the extension says "Sure, we do that" and starts doing its thing. If you are unlucky and the grabby extension is asked the question before the actual runas extension, the runas command winds up being hijacked by the grabby extension.

    (This is the same mistake that causes the Copy To and Move To commands to behave strangely if you add them to the context menu: They assume that the only reason they are invoked is that the user invoked their command, because they weren't designed to be hosted by context menus to begin with! They were designed to go into the toolbar, and the toolbar hosting code never invoked commands by name. It's like taking a ladder and using it as a bridge between two tall buildings. Sure, you can now cross from one building to another, but you also run a serious risk of falling to your death.)

    A variation on the initial problem is "I found that after installing a particular program, I can't run anything from the Start menu." I know of at least two programs which install context menu extensions which steal the "open" command on executables.

    This problem is sufficiently prevalent that there is a special compatibility flag that can be set on a shell extension to say, "This is a grabby shell extension that steals commands. Never ask it if it supports anything, because it will always say yes!"

    Notice that the "MoveTo CopyTo Context Menu" is on the list, which I find interesting because MoveTo/CopyTo was never meant to go on the context menu in the first place. Going back to our analogy, it'd be as if the ladder company issued a safety bulletin to warn people of problems that can occur if you use it as a bridge between two tall buildings!

  • The Old New Thing

    Why can't I use the file sharing wizard if I exclude inheritable permissions from a folder's parent?


    In Windows Vista and Windows Server 2008, if you go to a the advanced security settings for a directory and uncheck "include inheritable permissions from this object's parent", then go back to the Sharing tab, you'll find that the "Share" button is disabled. Why is this? We don't see this behavior on Windows 7 or Windows Server 2008 R2.

    (Yes, a customer actually noticed and asked the question.)

    The sharing wizard in Windows Vista and Windows Server 2008 does not support folders with the SE_DACL_PROTECTED security descriptor control bit because it isn't sure that it can restore the ACL afterward.

    And as the customer noted, this restriction was lifted in Windows 7 and Windows Server 2008 R2.

  • The Old New Thing

    How does Explorer calculate the folder size information in the folder tooltip?


    This information is accurate as of Windows 7; the algorithm may change for future versions of Windows. The information is being provided for the edification of computer network administrators, who are curious about random stuff like this since it can affect their network load.

    When you hover over a folder, Explorer shows an infotip (a special type of tooltip) which contains information about the directory, and the information that concerns network administrators is the "Size". How does Explorer calculate the size?

    Explorer calculates the size by performing a naïve recursive listing of the directory and adding up the sizes of all the files it finds. If the enumeration takes longer than three seconds, then Explorer gives up after three seconds and reports the size as "larger than X" where X was the size it managed to calculate so far.

    If you don't want Explorer to do this calculation, you can disable it from the Folder Options control panel by unchecking the box labeled Display file size information in folder tips.

  • The Old New Thing

    What happened to the Summary information created on Windows 2000 and Windows XP?


    In Windows 2000 and Windows XP, you could add Summary information on the Details property page to files of all types. Text files, image files, some crazy file your grandmother sent you in a file format you don't know how to open. If Windows supports storing the Summary information in the file itself (for example, in EXIF tags or in Structure Storage properties), then the information gets stored there. Otherwise, Windows stashes the information in an alternate data stream. Windows Vista dropped support for storing Summary information in alternate data streams. What happened?

    Support for storing Summary information in an alternate data stream was dropped in Windows Vista because alternate data streams were found to be too fragile. If you back up the file to a CD-ROM or email it to a friend or copy it to a thumb drive or upload it to a Web site or store it in a ZIP file, the alternate data stream ends up lost. It was determined that it was better simple not to allow users to create data that was so easy to destroy accidentally.

  • The Old New Thing

    How do I prevent users from opening TIF files?


    A customer had a question about their Windows XP installations. (This question was from several years ago, so the fine details aren't really relevant any more, but I'm actually telling this story for a commentary opportunity.)

    The customer wanted to disable all file associations for TIFF files. Their first attempt was by deleting HKEY_CLASSES_ROOT\.tif and HKEY_CLASSES_ROOT\.tiff. This successfully renders TIFF files with a generic document icon, but when the user double-clicks the file, the registration is re-established and Windows Picture and Fax Viewer opens the file.

    The company had some strange company security policy that says that TIFF files should not have any file association. I don't know the rationale behind it, but they did say that they only needed to block the default file association. If the user explicitly creates a new association via the Open With dialog, then that is not covered by the policy.

    Deleting the registrations doesn't work because Windows XP has an autorepair feature for certain commonly-corrupted file associations, and TIFF is one of them. If the TIFF registration is corrupted and the user is a member of the Administrators group, then Windows XP will restore the default association. (If the user is not a member of the Administrators group, then the usual "Windows cannot open this file" dialog box appears.)

    Therefore, the solution to the customer's odd problem is not to delete the TIFF registrations (which causes them to be detected as corrupted) but rather to simply set a new default handler for TIFF files that merely displays a message to the user. If you're willing to use the Windows Script Host, then it's a one-line program:

    WScript.Echo("TIFF file associations are disabled.")

    If you have been reading carefully, you have already noticed a serious problem with the customer's configuration: The fact that they are seeing the TIFF autorepair code kicking in means that they are letting their employees run with Administrator privileges, which means that their so-called "security requirement" is like worrying about employees being able to sneak into the building through a ventilation grating, when you give everybody a key to the front door.

  • The Old New Thing

    Why doesn't the Version tab show up for very large files?


    If you have a really large file and try to view its properties in Explorer, you may find that the Version tab doesn't appear. What's going on?

    The Version tab uses the GetFileVersionInfo family of functions to obtain version information from files. It so happens that the GetFileVersionInfo function works by calling LoadLibraryEx(LOAD_LIBRARY_AS_DATAFILE) and then using functions like FindResource to locate the version resource so it can allocate a buffer to hold the version resource plus additional data to assist in character set translation.

    If the file is larger than the available address space in the Explorer process, then the call to LoadLibraryEx will fail due to lack of address space into which to map the image. Library not loaded means no version resource to show you.

    When we explained this behavior to a customer, the customer wanted to know the exact file size at which the problem occurs.

    There is no single exact file size at which the problem occurs because the amount of available address space is determined by large numbers of factors which cannot be boiled down to a simple description. It depends on the pattern of memory allocation that took place inside Explorer, which shell extensions and DLLs got loaded at what point in time, where they got relocated to, which ones got unloaded relative to others loading, how much memory they allocated and where those allocations ended up.

    It's like asking the airline, "I know that the later I make my reservation, the less likely I'm going to get the exact seat I want. What is the cutover point before which I will get a window seat and after which I won't?" There is no specific point in time where "all reservations before this point will definitely get a window seat, and all reservations after this point will definitely not get one." It all depends on the pattern of requests before you make your reservations. Indeed, it's even possible that if you had made your reservation later, you would have gotten that window seat, because somebody who had a window seat called in a cancellation.

    One customer apparently didn't understand the unpredictability of the cutover point and asked, "Is there a way to change this limit?"

Page 7 of 26 (254 items) «56789»