I think the hard part would be to test and check all corner cases.

Perhaps I'll be able to take this issue but can't guarantee.

I'm going to finish PR soon. I've got time to dig into Rust.

My initial take was to fix filename generation, and I've done it. But now I see that it can be achieved using GetFileInformationByHandleEx , as it accepts HANDLE and gives various info form file (we already are using similar funtion for getting information on regular size). Using handles must be marginally faster.

Also I've found other issues with apparent size on Windows platform: it shows size inconsistent with windows explorer for small files. Windows explorer shows 0, which means it's stored inside parent directory, but current solution shows size. And also we don't calculate size of alternate file streams, but that calculation can be costly on performance.

I think that inconsitencies can be addressed later.

P.S. source material: https://devblogs.microsoft.com/oldnewthing/20160427-00/?p=93365

Fun fact. Comporssed size reports incorrectly:

File: test-data\b4000_rand_c
 FILE_STANDARD_INFO { AllocationSize: 8192, EndOfFile: 4000, NumberOfLinks: 1, DeletePending: 0, Directory: 0 }
 FILE_COMPRESSION_INFO { CompressedFileSize: 4000, CompressionFormat: 2, CompressionUnitShift: 16, ChunkShift: 12, ClusterShift: 12, Reserved: [0, 0, 0] }
 GetCompressedFileSizeW: 4000

AllocationSize struct is most reliable (when calling GetFileInformationByHandleEx)

but it gives minuscule discrepancy on small files

File: test-data\b23_rand_c
FILE_STANDARD_INFO { AllocationSize: 24, EndOfFile: 23, NumberOfLinks: 1, DeletePending: 0, Directory: 0 }
FILE_COMPRESSION_INFO { CompressedFileSize: 23, CompressionFormat: 2, CompressionUnitShift: 16, ChunkShift: 12, ClusterShift: 12, Reserved: [0, 0, 0] }
comp_size: 23

24 bytes instead of 23. But I think it's not a big deal.