With the release of FolderSizes v8.3.150, support for Windows Server 2016 has become official.
FolderSizes continues to provide cutting-edge support for new Microsoft operating system releases, this time even ahead of Windows Server 2016 general availability. Our continued goal is to ensure that you have the disk space analysis, reporting, and management capabilities you need when you need them – across all Windows platforms.
One question that we receive from our customers on a fairly regular basis is “How can we produce a listing of all the folders (or files) in a specific directory?” Often the customer will also want to print and/or export said listing.
This is a perfect job for the FolderSizes Search tool. In fact, FolderSizes can product a “flat” (non-hierarchical) list of files and/or folders that includes a considerable amount of useful information – far more than what is exposed by other software utilities. For example, creating a list of folders will yield their size, allocated size (e.g. “size on disk), owner, attributes, path and name lengths, folder depth, and much more.
Not only does FolderSizes Search produce detailed results, but those results can be exported, printed, and even managed (copied, deleted, or archived) directly from within the tool. You can schedule production of said reports, as well as load and save them as needed. You can also search multiple local and/or network file systems in a single pass.
So let’s walk through a simple example of how to use FolderSizes Search in this capacity. Let’s say we want to list all the image files in a specific directory.
- Click the Search button in the main window ribbon bar
- On the Search Paths tab, click the New Path button and browse for the folder you wish to search
- Switch to the Search Rules tab and click the New Rule button, then select New File Rule
- Optionally give the rule a useful name (it will named something like “Rule #1″ by default)
- In the Name tab of the file rule editor, click the Presets button and select Images
- Click OK to save the rule
At this point we have a single file rule configured to match the file extensions of a wide range of image file types and we simply need to run the Search by clicking the Start button. Results will begin to appear as soon as they’re available.
Of course, this is just the beginning in terms of what’s possible. You can also create folder rules, with criteria designed to match specific folders (rather than files) – or you can use a combination of the two. File and folder rules can match a wide range of criteria such as name (as we saw in our example above), attributes, size, name or path length, age, owner, folder depth, and more.
In summary, the Search tool is very versatile and can produce folder/file listings that include many of the critical report attributes (such as size and allocates size) that you expect from FolderSizes. If you have any questions about how to achieve a specific goal, please don’t hesitate to reach out to us – we’re happy to help.
FolderSizes provides robust support for long NTFS file system paths. In this article, I’ll discuss how to you can search for long NTFS paths using FolderSizes. Spoiler alert – it’s incredibly easy.
First, start FolderSizes and click the Search button in the main window ribbon bar. The Search window will appear.
Click the Search Paths tab and enter as many paths as you wish to search. This can be any combination of local and network paths.
Once you’ve defined the paths that you’d like to search, click the Samples button in the Search window toolbar. Here you’ll be able to choose from a number of built-in search samples that FolderSizes provides out of the box. In this case, select the one named “Find Long File and Folder Paths.xml”.
After the sample is loaded, the Search Rules tab will automatically be selected so you can review the associated rules. In this case, you’ll see two predefined rules – one for files, and one for folders (since we’re interested in finding both). Let’s double-click the file rule to review its criteria:
As you can see from the screenshot above, the Name Len tab of the file rule editor specifies is configured to match paths with more than 255 characters in them. Also note that the Count the full path length option is selected (without this, only the length of the file name would be considered when evaluating the rule).
Close the File Rule Editor window and click Start in the Search window to execute the search. Upon completion, you’ll be presented with a full list of files and folders with paths exceeding a length of 255 characters. This allows you to review the size, allocated size (e.g. “size on disk”), and much more (right-click the search result listing column header to customize the report).
So there you have it, a quick and easy-to-use means of finding long NTFS file system paths. Very handy considering that a number of programs and systems are unable to process long file system paths correctly.
Just a quick note to let you know that FolderSizes 8.2 is now available.
This minor version release introduces a handful of new features. Most notably, FolderSizes 8.2 now includes summary footers for all file reports – including full support for most export file types (the ones that make sense), printing, etc. This is a feature that users have been requesting for a while now, so we’re happy to get it into your hands.
FolderSizes 8.2 also includes another popular feature request – the ability to move or copy files (via the File Operations dialog) while retaining the existing folder structure.
We’ve also improved support for Windows Server Data Deduplication in the duplicate files report, updated default file report column layouts, improved the zip compression progress dialog, updated the task scheduler listing to support sorting, updated the help file, and fixed a number of bugs.
Feel free to download FolderSizes 8.2 whenever you’re ready – it’s a free update for all existing FolderSizes 8 license holders. And if you’re still running an older major version of FolderSizes, we recommend upgrading today – you’re missing all the good new stuff!
Windows Server and some third-party hierarchical storage management (HSM) systems provide offline file management capabilities, allowing policies to be established which cause old or infrequently used files to be moved to cheaper and slower storage systems. In such cases, the original file is replaced with a small “stub” file that resolves to the new location.
So how does FolderSizes report on such files? Typically an offline stub file will occupy a single cluster on the file system – and that’s exactly what FolderSizes (correctly) reports in the vast majority of cases.
However, we have seen rare instances where the size of offline stub files was reported incorrectly. In order to understand this scenario, it’s important to know that (by default) FolderSizes assigns itself backup and restore privileges whenever possible. It does this in order to decrease the likelihood of permissions issues, thereby improving visibility into the target file system.
However, occasionally we’ve run across HSM appliances that report the size of stub files in terms of their original values (before the file was moved offline) when queried by an application with backup/restore privileges assigned, assumedly because this would be the size occupied by a backup. This can be a problem for FolderSizes, since we want to know actual disk space usage for files on the storage device (not their offline file sizes).
FolderSizes offers a couple potential workarounds for this problem. First, in Options | Scanning, users can elect to disable the assignment of backup/restore privileges to FolderSizes, which will usually fix the problem at its source. The same option screen also allows users to explicitly set the allocated size of offline files according to some predefined value (a single cluster, 4Kb, 8Kb, or 16Kb), which can be used to work around the problem.
Finally, it might be worth noting that FolderSizes will never trigger the retrieval of offline files during the course of any analysis or reporting process (generally a process must read from or write to an offline file in order to trigger a recall).