Size reporting discrepency for NTFS compressed folders

[luckywhale]

Hi, many thanks for the magical Everything.

I am running the latest alpha of Everything 1.5 (which is magnificent by the way) in Windows 10 (22H2).

There seems to be a problem in reporting of folder sizes for NTFS compressed folders (if compressed using XPRESS 16K scheme using 'compact.exe' tool in Windows). I am attaching the screenshot showing its size on disk (in Everything and also in Explorer and TreeSize utility). Also the reported folder in Everything changes dynamically as the folder is compressed/uncompressed (as expected?).

Also this occurs, for not only this particular folder, but also for other folders compressed in this method.
Interestingly it does not occur (=size is correctly reported and does not change when compressing) for folders compressed using the standard NTFS compression option provided in the GUI of Explorer itself. It only occurs when other compression schemes (e.g. XPRESS 16K, etc.) are used (which can be done using the Windows API or the 'compact.exe' utility).

FYI, the folder in question has no hardlinks or symbolic links (reparse points, etc.) in it. It is just a typical folder.

If more info is needed will be happy to provide.

Thanks.

[therube]

(Since you've mentioned compressed folders, & as I've never met them - before today, I'll just link to, Compression / New Thoughts.

And I'll note that Servant Salamander [file manager] while it sees & notes that compressed files are compressed, it does not show compressed file [or directory] sizes, rather their uncompressed size.)

[luckywhale]

Thanks for reply.

The problem is that "size" (not "size on disk") column should be (intuitively) insensitive to actual compression/decompression state and also the reported "size" cannot logically be smaller than "size on disk" (which TreeSize is showing).

IMHO, this might be related to handling of NTFS reparse points in Everything.

[void]

Thank you for your feedback luckywhale,

Please try a search for:

\.vscode\extensions\codeium.codeium-1.4.16\

Check if Everything is finding the 25 files and 4 folders.

Roughly check if the sizes add up to the folder size Everything is reporting.



Everything NTFS indexing (Tools -> Options -> NTFS) does not follow reparse points.
Use folder indexing (Tools -> Options -> Folders) to follow reparse points.



Are you excluding any files/folders under Tools -> Options -> Exclude?
The folder size is calculated from files in your index (not from disk)

[luckywhale]

Thanks for replying David,

I performed what you requested and some other actions and have summarized the results in aattached screenshots.

No changes were made to file permissions, Everything settings, etc. between the screenshots.
Only the folder is compressed/decompressed.

There are no file/folder exclusions (every thing is indexed).

I referenced reparse points because (as far as I know) it is also the mechanism for implementing compression, encryption, etc. in NTFS.
As I mentioned there are no symbolic links, hard-links or NTFS folder junctions in that folder.

Also I checked and file permissions are standard and the folder contents are not used by any program at the moment (nothing locked).

[luckywhale]

After some more testing, I found out on my C:\ drive these files had no "size" fields even though there are no exclusions and they are not locked either. All of them are accessible (not locked or permission restricted and I have no trouble opening them in a viewer) but are COMPRESSED (using XPRESS 16K).

You can check for files which have no size field (not "0" size but empty size field) in Everything: Simply sort files by size in a given drive/volume and then look at the bottom of the list to find files with empty size fields!

I should mention that the vast majority of files have no problem and their size information is available and correct (even if they are compressed with whatever scheme). Only certain files show this odd behavior where their size information is unavailable in Everything if they were compressed using compact.exe (XPRESS 16k) but this consistently happens for them (if they are uncompressed and re-compressed again the same thing happens).

The problem seems to be when Everything is notified of their modification (via USN journal?) which is their compression by compact.exe, for some reason, it is unable to access their size information at the moment for those particular files!

I have also attached my relevant settings for indexing C:\ drive.

Thanks.

[void]

Thank you for the information luckywhale,

Everything 1.5.0.1360a fixes an issue with reading the file size of compressed files.

Everything was missing the file size due to an optimization.
This fix should show the correct size for your compressed files.

[luckywhale]

Many thanks for the continual improvements to Everything 1.5.

I tested and can confirm that all file sizes (regardless of the compression state and its change via whatever mechanism: GUI or compact.exe) are being reported and folder sizes (which contain them) are displayed as expected, in the latest build.

Thank you.