This pull request ended up much larger than the branch name (add-NTFS-special-file-support) sounds.
In pursuit of 100% used-space-accounting-for (as NTFS "misreports" free space), altWinDirStat now displays the size of the NTFS Master File Table, and I've implemented experimental support for displaying the sizes of other NTFS metafiles.
I've also fixed the annoying issue (#9) where running altWinDirStat for the first time - only where the vanilla version of WinDirStat has also not been run - would display a garbled file tree & file type list.
That bug wasn't visible on my dev machine because I never actually deleted the registry key where settings are stored. Oliver Schneider & Bernhard Seifert included Delete HKCU\Software\seifert\windirstat in the original test plan, which I don't really use. Shame on me.
This pull request does suffer from one regression: working with very large folders (number of items) is a bit slower, sadly. I fixed an annoying bug where the last item in the list view would appear after the parent folder had been collapsed. I refer to it as a "zombie item".
This pull request ended up much larger than the branch name (
add-NTFS-special-file-support
) sounds.In pursuit of 100% used-space-accounting-for (as NTFS "misreports" free space), altWinDirStat now displays the size of the NTFS Master File Table, and I've implemented experimental support for displaying the sizes of other NTFS metafiles.
I've also fixed the annoying issue (#9) where running altWinDirStat for the first time - only where the vanilla version of WinDirStat has also not been run - would display a garbled file tree & file type list.
That bug wasn't visible on my dev machine because I never actually deleted the registry key where settings are stored. Oliver Schneider & Bernhard Seifert included
Delete HKCU\Software\seifert\windirstat
in the original test plan, which I don't really use. Shame on me.This pull request does suffer from one regression: working with very large folders (number of items) is a bit slower, sadly. I fixed an annoying bug where the last item in the list view would appear after the parent folder had been collapsed. I refer to it as a "zombie item".
As an example, here's the my AppData folder, expanded:
Here it is, collapsed, with "zombie item":
Here's the collapsed folder, without the "zombie item" (fixed):
Backend changes:
CDC
with the rawHDC
, which improvesconst
-correctness, and allows me to check return values whereMFC
doesn't.CTreeListItem*
s withconst CTreeListItem*
s.TRACE
s.