Because of that I request that both related threads be locked.-tomos
Dunno if they need to be locked - they're pretty dead now from my viewpoint.
One last thing coming up in a few, though, since I promised it: working on a small test to see what happens wrt. very small files (MFT-resident) when you apply compression.
Here, results from testing some very small files on an NTFS volume with 1k clusters. The files were highly comrpessible (filled with A's). The lines with "x is UNcompressed" (etc) are from a small tool I whipped up, the middle parts is the output from Microsoft's COMPACT.EXE.
small100.txt is UNcompressed, 100/100, (MFT resident), 1 fragments
small500.txt is UNcompressed, 500/500, (MFT resident), 1 fragments
small1000.txt is UNcompressed, 1000/1000, 1 fragments
small5000.txt is UNcompressed, 5000/5000, 1 fragments
====================================================
Compressing files in R:\temp\z\
small100.txt 100 : 100 = 1,0 to 1 [OK]
small1000.txt 1000 : 1000 = 1,0 to 1 [OK]
small500.txt 500 : 500 = 1,0 to 1 [OK]
small5000.txt 5000 : 1024 = 4,9 to 1 [OK]
4 files within 1 directories were compressed.
6.600 total bytes of data are stored in 2.624 bytes.
The compression ratio is 2,5 to 1.
====================================================
small100.txt is compressed, 100/100, (MFT resident), 1 fragments
small500.txt is compressed, 500/500, (MFT resident), 1 fragments
small1000.txt is compressed, 1000/1000, 2 fragments
small5000.txt is compressed, 5000/1024, 2 fragments
Observations:
1) MFT-resident data stays resident - good!
2) The really small files aren't actually compressed (GetCompressedFileSize == GetFileSizeEx, see MSDN) - they are flagged compressed, though, so will be compressed once they grow.
3) For compressed files, we get "size on disk" (taking clusters into account), not "actual numCompressedBytes" - which makes sense.
4) When compressing non-resident files, we get one excess fragment.
