On 8/26/22 13:59, jhol (@jhol) wrote:
The tracing of `GetDiskFreeSpaceA` is copy-pasted from the code further up in the test, where the function is tested with DOS paths.
Stepping back... what do we want this test to look like? `GetDiskFreeSpaceA` can legitimately fail for a variety of reasons, which is why other parts of the unit test stop short of doing `ok(ret == TRUE, ...)`. In similar fashion, this test code simply gets all the drive NT GUID paths (which come from `mountmgr.sys`), and then verifies that `mountmgr.sys` can cope with `FileFsSizeInfo` queries on the paths it listed out.
Okay, I didn't look at the rest of the test.
It strikes me as more than a little unfortunate that we're saying "can fail" without explaining what those failures are or why they're legitimate. I wouldn't immediately think that GetDiskFreeSpaceA() should ever fail on Windows.
`git blame` shows some of the prior error codes, though unfortunately almost none of the commits are explained and few of the error codes make sense. Based on 3826193f33fb I guess at least some are due to broken virtual filesystem drivers, and I guess some others would be consistent with a network drive that was taken down...
Maybe we could at least test that GetDiskFreeSpaceA() of the C drive works, since I imagine that should never fail. As it is the test seems pretty much useless...
Of course this is all pretty much orthogonal to this patch set.