Let’s talk about what we’ve been working on for our upcoming FolderSizes v4.6 release.
First and foremost, v4.6 contains a new integrated scheduling facility. With this tool, you can schedule the execution of any FolderSizes report type and export those results in a variety of formats. Here in our development labs, we’ve scheduled the generation of all of FolderSizes’ various report types, exporting each of them (in HTML format) to a shared folder on our network (effectively building an archive of data storage reports that speed and simplify storage hotspot identification, as well as providing historical context).
The next major focus of FolderSizes v4.6 is performance. Nearly every feature has received a comprehensive performance and resource usage evaluation, and this has process resulted in:
- The introduction of a new file owner data lookup cache
- Numerous improvements to our folder analysis data caching technology
- A nearly 60% memory usage reduction in many file report scan scenarios
- Numerous performance boosts when scanning remote (network) paths
- New options that provide more granular control over scan-time performance
Some of these improvements might sound a bit technical and geeky – but believe me, they amount to a serious performance and resource usage improvement in v4.6.
There are tons of other improvements as well – improved visual theme switching, “filename only” duplicate file matching, a greatly improved duplicate file report HTML export format, a new “allocated” column in several of the file reporting detail views, and much more. We also threw in a handful of bug fixes for good measure.
FolderSizes v4.6 is a free upgrade for existing v4 license holders. Get yours now – fresh off the compiler.
FolderSizes is featured in the Toolbox : New Products for IT Pros section of Microsoft TechNet magazine (May, 2008 edition).
It’s a really nice review, although I’m not quite sure how Greg (the reviewer) managed to capture such an ugly screen shot of the main window. To each their own, I suppose.
With MS Vista Service Pack 1 now available, some users have observed a non-trivial hit to their available disk space after installing the update.
What’s happening is that SP1 backs up previous versions of many components during installation, consuming quite a bit of disk space in the process. If you’re completely confident that you won’t need to uninstall SP1, you can actually reclaim that space. Vista SP1 includes an optional tool called Vsp1cln.exe which will remove the files backed up during installation. After the Vista SP1 installation completes, Vsp1cln.exe will be located in your Windows\system32 directory. You can run it by dropping to a command prompt (or press “Winkey + R” on your keyboard) and and typing Vsp1cln.exe and pressing Enter.
The cleanup utility will warn you that you’re about to make your Vista SP1 installation permanent, and prompt you for confirmation. Once confirmed, the cleanup process will begin. Again, don’t execute this file removal utility unless you’re certain that you won’t need to uninstall Vista SP1. But if you’ve created a full backup of your computer prior to installing Vista SP1 (I actually prefer to image my entire system before doing this sort of thing), this may not be much of a concern.
So how much disk space can you reclaim by running Vsp1cln.exe? Most users are reporting just under a gigabyte of recovered space, depending upon which version of Vista is installed. Your mileage may vary. And if you still need a better understanding of how your disk space is being consumed, well then you need FolderSizes.
The new Duplicate File Detective release is larger in scope, and contains a considerable number of feature enhancements. If you haven’t tried this powerful, dedicated duplicate file management tool – please do so soon.
Both releases are free upgrades to anyone who owns a license for the same major version number of the product.
We’ve received a few reports from users that are unable to see one or more mapped drives from within FolderSizes when running it on Windows Vista. Unfortunately, this issue is the result of a Vista security design decision and impacts a broad range of software applications (not just FolderSizes).
The root problem is that (by default) Vista creates two user security tokens when you log in – the first being a default “filtered” (or non-admin) token and the second having administrative capabilities. Usually, you gain access to the latter (admin token) only after being prompted by a User Account Control (UAC) consent dialog.
FolderSizes contains an application manifest that causes it to run with the highest permissions available to the user, which on Windows Vista means you’ll be prompted (by UAC) to allow the process to “elevate” itself and run within the context of your full admin token. This is important when using FolderSizes because it helps to ensure full access to the various storage resources that the software analyzes.
So why does any of this impact the visibility of mapped drives within FolderSizes? Because under Vista when you map a network share it is linked to the current logon session for the current process token. This means you won’t have access to the mapped drive from your alternate, admin token (which FolderSizes runs under by default).
One solution is to run Windows Explorer “as administrator” (which you can do with a right-click of the Windows Explorer shortcut) and duplicate your mapped drives from there. They will then be visible to any process that elevates itself during execution.
Another option is to use UNC paths whenever possible. If you find that you can’t access a mapped drive in Vista (because you created the mapping with a restricted account token), you might consider just entering the UNC path (e.g. \\server\share) into the Path box near the top of the main FolderSizes window.
Yet another option is to make a registry change that will allow Vista to share network connections between your filtered access token and your full administrator token. From MS Knowledge Base article 937624, you can do this as follows:
- Click Start, type regedit in the Start Search box, and then press ENTER.
- Locate and then right-click the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
- Point to New, and then click DWORD Value.
- Type EnableLinkedConnections, and then press ENTER.
- Right-click EnableLinkedConnections, and then click Modify.
- In the Value data box, type 1, and then click OK.
- Exit Registry Editor, and then restart the computer.
Of course, the usual warnings apply – don’t edit your Windows registry unless you know what you’re doing (and preferably have a backup handy just in case something goes wrong).