SpaceObServer

Every disk space analyser tells you what is on a drive right now. SpaceObServer tells you what changed, because it writes each scan into an SQL database and keeps the results, so a folder’s size becomes a line on a chart rather than a number you wrote down last month. That single design decision is what separates it from everything else in the category.

The scanning is done by a background service, not by the window you look at. Point it at a location, set an interval, and it collects on schedule whether or not anyone is signed in. The interface you open later is a reader for that database, which is why it shows a folder’s history and its growth since the previous scan while a conventional analyser shows only today.

If all you need is to find out why a laptop drive is full this afternoon, TreeSize does that faster and with far less setup.

The database is the product

Scans land in an SQL database, and you can send different scans to different databases on the same server, which is how you separate departments and then control who reads what through database permissions rather than through the application.

History depth is governed by one setting that people miss. Each scan target has a purge value in days, and size information older than that is discarded, so the History chart can only reach back as far as that number allows. Set it to thirty and you have a month of trend data no matter how long SpaceObServer has been running.

Worth thinking about before you start collecting, because the history you did not keep cannot be recovered later.

Keeping the figures current without rescanning

Full rescans of a large share are slow, and this is the answer. On local NTFS volumes SpaceObServer reads the change journal, the log the filesystem keeps of its own modifications, and applies those changes to the database continuously. The result is disk usage information that stays current between scheduled scans instead of aging until the next one.

Two limitations attach. It works on local NTFS drives only, so network shares are excluded, and it activates for an entire drive rather than the branch you selected. Neither is unreasonable, both catch people out.

What it can point at besides a local drive

The target list in SpaceObServer goes considerably further than local volumes and network paths. It scans Unix hosts, Amazon S3 buckets, Azure Blob Storage, WebDAV endpoints, Exchange mailboxes and Novell NetWare volumes, which together cover most of what an established organisation has accumulated.

SharePoint is handled with a detail that shows someone thought about it. There is an option to check whether previous versions of each file exist and add their sizes into the allocated space figure, because a document library where everyone saves twenty revisions occupies far more than the current files suggest.

Authentication for those scans goes through directory-based credentials, either as a user or with a certificate.

The options that cost you scan time

Several of the more interesting features in SpaceObServer are switched off by default, and the reason is always performance.

MD5 checksums are the main one. Enable them and duplicate file detection becomes possible, and the checksums are calculated by the service while it has no scan queued rather than during a scan, so the impact is spread out. The database grows noticeably in exchange. Build on top of that and it will also report duplicate or similar folder structures, which is how you find the same project copied into four departmental shares.

Alternate data streams and hardlink tracking are likewise disabled, because examining every file for them is slow. Turn them on when your allocated size figures look wrong rather than as a matter of routine.

Permissions can be stored in the database too, which unlocks a view showing where permissions have changed between scans, and that is a security report as much as a storage one.

The views you will actually open

Beyond the directory tree there are tabs for history, extensions, users, size distributions and the largest files, and the useful ones are not the ones you would guess.

The users view is the one that changes conversations, because it attributes space to file owners, and a report naming the five people who account for a third of a share gets results no folder chart will. Extensions answers what type of data is growing. Distributions shows whether you have a few enormous files or a million small ones, which determines whether the fix is deletion or archiving.

The visual treemap that free tools are known for is present but not the point here, and honestly a free treemap analyser draws a prettier one. Numbers and trends are what this is for.

Reporting and what happens after a scan

Exports from SpaceObServer cover PDF, Excel, HTML, CSV and plain text, plus direct printing and email, and any of them can be attached to a scheduled reporting action so the report arrives without anyone opening the application. This is the feature that justifies the whole arrangement for anyone who has to send a monthly storage summary upward.

Data lifecycle actions run after a scan and act on what was found, moving or removing data that matches your rules. Powerful and worth approaching carefully, since a rule that looked right in a dialog behaves differently against a real share. For a one-off relocation of old files, Robocopy is the safer instrument because you can see the command before it runs.

There is also a currency figure per gigabyte you can set per scan, which then appears as a column beside every folder. Departmental chargeback in a storage tool is unusual, and if you do that kind of accounting it saves building the calculation in a spreadsheet.

Filters, access lists and the trap in both

Exclude patterns keep noise out of a scan, matching either a path or a file mask, and regular expressions are supported for anything more involved.

Here is the trap, and it is documented but easy to miss. The filter has to use the same notation as the scan location. If the scan is defined by a UNC path and your filter is written against a mapped drive letter, the filter is silently ignored and nothing tells you. When an exclusion appears to do nothing at all in SpaceObServer, this is almost always why.

Each scan also carries a list of users and groups permitted to see it in the interface, with wildcards allowed, entered without the domain part. That granularity is what makes it usable in an environment where one team should see their own shares and nothing else.

Automation is available through both a scripting interface and a command-line parser, and there is an option to build a full-text index for a companion search tool, though for plain filename searching Everything is quicker to reach for.

Conclusion

This belongs to whoever answers for storage in an organisation with shares that keep filling up and no explanation for it. The combination of archived history, ownership attribution and scheduled reports turns an argument about disk space into a document, and nothing in the free tier of this category does that.

It asks for real commitment in return. There is a database to provision, a service account to sort out, a purge policy to decide before the data you want exists, and a small collection of documented traps around filters and change journals. Anyone who wants to know why one drive is full today should install a one-off snapshot scanner instead and be finished in five minutes.