Confusing interaction with LZNT1-compressed files #85

Activity

1. Freaky commented on Feb 16, 2023

   

   Freaky

   on Feb 16, 2023

   Owner

   More actions

   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.
2. wigwoo1 commented on Feb 17, 2023

   

   wigwoo1

   on Feb 17, 2023 via email

   Author

   More actions

   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 <#85 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APCUJWTKM3BG3MD3FVNC6GLWXZCOBANCNFSM6AAAAAAU5DFZJQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>
3. Freaky commented on Feb 17, 2023

   

   Freaky

   on Feb 17, 2023

   Owner

   More actions

   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.
4. Freaky

   added

   bugSomething isn't workingSomething isn't working

   on Feb 17, 2023
5. Freaky

   added this to the v0.11.0 milestone on Feb 17, 2023
6. Freaky

   self-assigned this

   on Feb 17, 2023
7. Freaky

   changed the title [-]Decompressing doesn't work[/-] [+]Confusing interaction with LZNT1-compressed files[/+] on Feb 17, 2023
8. wigwoo1 commented on Feb 18, 2023

   

   wigwoo1

   on Feb 18, 2023 via email

   Author

   More actions

   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 <#85 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APCUJWQNQ6VOFM4AXNRJDDTWX74QRANCNFSM6AAAAAAU5DFZJQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>