GetDiskFreeSpace used to require a volume root

GetDiskFreeSpace was superseded by GetDiskFreeSpaceEx in Windows NT 4.0 and Windows 95 OSR 2. GetDiskFreeSpaceEx solves the problem of requiring 32 bit applications to perform 64 bit math on the return values to obtain the information they actually wanted, but the initial version of GetDiskFreeSpace had a more subtle flaw: it required to operate on volume roots.

Today, that's a very bad idea. A namespace could redirect across volumes for a huge number of reasons: mount points, symbolic links and DFS namespaces to name a few. But at the time NT 3.1 was being released, none of these existed: the world was a much simpler place of drives, drive letters, and drive free space.

This creates a double whammy problem for anything trying to use GetDiskFreeSpace: it must operate on a volume root, but there were no APIs to determine a volume root (GetVolumePathName didn't exist.) At the time, applications were expected to just truncate a path to a drive letter or share and use that; doing so today wouldn't really be correct, but it's the only way it worked when GetDiskFreeSpace first arrived.

Fortunately, independently of GetDiskFreeSpaceEx, GetDiskFreeSpace now supports being called on arbitrary directories (as of NT 4.) So unless your application needs to run on older platforms than that, you shouldn't need to write your own code to guess the location of a volume root given a directory. Unfortunately, since the API exists with the same signature but a subtle behavior change, it's not possible to determine whether the path truncation is required without calling GetDiskFreeSpace and checking for failure, then performing the truncate if needed.