Freaky / Compactor

A user interface for Windows 10 filesystem compression
MIT License
1.18k stars 49 forks source link

Confusing interaction with LZNT1-compressed files #85

Open wigwoo1 opened 1 year ago

wigwoo1 commented 1 year ago

I've been using this software for a few years and one thing I've noticed is that decompressing has never worked. I always have to instead go to the properties of my drive and uncheck the "Compress this disk to save space" in order to decompress

Freaky commented 1 year ago

The "Compress this disk" checkbox - and its file and folder counterparts - are the old NTFS LZNT1 compression system, which is completely separate from the WoF compression system Compactor uses. If you have that set, then decompressing in Compactor will just be recompressing your files with LZNT1.

If that's the case I'd guess you're determining that "decompressing doesn't work" by observing that Compactor continues to report space savings - but that will be a result of LZNT1, not Compactor. You'll probably see the compression reduce somewhat because it's a less effective system. If you're seeing no change at all that would be unusual.

wigwoo1 commented 1 year ago

Correct. No change at all.

Say I have my disk compressed using windows

Then I analyze the disk with Compactor

Compactor will see those compressed files and tell me I'm saving 200GB

But if I hit decompress, I don't end up losing any space and nothing gets decompressed

Compactor just runs through all the files in roughly a minute false reporting that my "Saves" space is going away but not a single byte is changing in the windows properties of the disk

Instead I'm forced to decompress the disk using Windows which takes well over 24 hours and then I can finally compress it with Compactor

On Thu, Feb 16, 2023, 10:36 AM Thomas Hurst @.***> wrote:

The "Compress this disk" checkbox - and its file and folder counterparts - are the old NTFS LZNT1 compression system, which is completely separate from the WoF compression system Compactor uses. If you have that set, then decompressing in Compactor will just be recompressing your files with LZNT1.

If that's the case I'd guess you're determining that "decompressing doesn't work" by observing that Compactor continues to report space savings

  • but that will be a result of LZNT1, not Compactor. You'll probably see the compression reduce somewhat because it's a less effective system. If you're seeing no change at all that would be unusual.

— Reply to this email directly, view it on GitHub https://github.com/Freaky/Compactor/issues/85#issuecomment-1433281914, or unsubscribe https://github.com/notifications/unsubscribe-auth/APCUJWTKM3BG3MD3FVNC6GLWXZCOBANCNFSM6AAAAAAU5DFZJQ . You are receiving this because you authored the thread.Message ID: @.***>

Freaky commented 1 year ago

But if I hit decompress, I don't end up losing any space and nothing gets decompressed

Ah, right, I don't actually do a second GetCompressedFileSizeW call on the decompress path, I just assume it decompresses to the full size:

fi.physical_size = fi.logical_size;

I do have a check for LZNT1 compression to mark them as incompressible, but it's helpfully skipped if the file's compressed size is less than the logical size. And in reality the correct thing to do would actually be to mark it as compressible, because Compactor can't decompress it, but it might be able to compress it more effectively.

Instead I'm forced to decompress the disk using Windows which takes well over 24 hours and then I can finally compress it with Compactor

I'm currently in the middle of a rewrite, with a new GUI and a new multithreaded backend - shouldn't be too much longer. I'll make sure I test this so it actually works properly.

wigwoo1 commented 1 year ago

Thank you very much for the explanation. I definitely look forward to your future work

On Fri, Feb 17, 2023, 5:36 PM Thomas Hurst @.***> wrote:

But if I hit decompress, I don't end up losing any space and nothing gets decompressed

Ah, right, I don't actually do a second GetCompressedFileSizeW call on the decompress path, I just assume it decompresses to the full size:

fi.physical_size = fi.logical_size;

I do have a check for LZNT1 compression to mark them as incompressible, but it's helpfully skipped if the file's compressed size is less than the logical size. And in reality the correct thing to do would actually be to mark it as compressible, because Compactor can't decompress it, but it might be able to compress it more effectively.

Instead I'm forced to decompress the disk using Windows which takes well over 24 hours and then I can finally compress it with Compactor

I'm currently in the middle of a rewrite, with a new GUI and a new multithreaded backend - shouldn't be too much longer. I'll make sure I test this so it actually works properly.

— Reply to this email directly, view it on GitHub https://github.com/Freaky/Compactor/issues/85#issuecomment-1435355943, or unsubscribe https://github.com/notifications/unsubscribe-auth/APCUJWQNQ6VOFM4AXNRJDDTWX74QRANCNFSM6AAAAAAU5DFZJQ . You are receiving this because you authored the thread.Message ID: @.***>