Repository navigation
Any new updates? Please? Open to fresh ideas? #97
Description
Ended up partially vibecoding up a similar project to compete with CompactGUI in Python, only to be guided to this project a few months ago. Even the name is similar... Great minds think alike I guess, but I'm kinda heartbroken.
As I see it, some things are sorely missing, both from Compactor and CompactGUI:
- dry-runs with enthropy analysis to correctly estimate how much free space can be gained with compressing, without actually making any changes to the files (checking file types only is a crutch, and CompactGUI's database can only do so much, and it hardly works outside of select Steam games)
- picking a compressibility threshold, to only compress files that are compressible by XX% instead of compressing everything, especially if it doesn't compress well, like many gigabytes of Chromium/Electron cache files (the horror)
- picking and choosing the right algorithm depending on file size (LZX isn't useful for files smaller than 256-512KB, XPRESS16K not useful for files under 64KB and so on)
- toggling resource-intensive LZX on/off based on how slow the CPU is, so that some beginner users who don't know what to choose don't shoot their already slow CPUs and Windows installations in the foot (best to pair it with the prior point above)
- HDD fragmentation safeguards
- a button or at least a tip to compress Windows with
compact.exe /compactos:alwaysfor the more desperate folks running on small SSDs
Also, internationalisation could be helpful. And a 1-click run to quickly compress certain directories, once dry-runs are implemented (so as not to accidentally compress the Steam directory full of already compressed games).
Activity
wefalltomorrow commentedon Sep 7, 2026
I’ve been working on a maintained fork of Compactor here:
https://github.com/wefalltomorrow/Compactor
Current release: v0.11.2
https://github.com/wefalltomorrow/Compactor/releases/latest
Some of the changes include:
Sampled compressibility analysis before compression
Configurable minimum estimated savings threshold
Estimated post-compression size and savings
SSD/NVMe-aware multithreaded analysis and compression
HDD detection with single-thread operation by default
Reduced-seek HDD analysis
LZX as the default compression mode
Removal of blanket file-extension exclusions
Reuse of valid Analyse results during compression to avoid duplicate sampling
In-app viewer for folders containing WOF-compressed files
Improved WOF/Win32 error handling and several correctness/performance fixes
Hopefully useful for anyone still looking for an updated Compactor build.
me-when-the-uh commentedon Sep 7, 2026
@wefalltomorrow One of the main problems I've found:
Before:
After:
Seeing how you too have used an LLM to churn out around a dozen new commits in 8 hours, you should point the LLM you've been using to my more mature program instead to take all the good practices and build upon that
wefalltomorrow commentedon Sep 8, 2026
@me-when-the-uh Thanks for the feedback — a few of these were fair, and I’ve changed them for 0.11.3.
Small correction first: Compactor isn’t spawning a separate process per file; it uses worker threads and calls WOF directly. But yeah, running those at Normal priority while also allowing too many LZX workers was a bad combo.
For 0.11.3:
On “everything using LZX” — LZX is just the default, not forced. All XPRESS modes are still there, and files are sampled first so poorly compressible files can be skipped.
I agree an automatic per-file algorithm mode could be useful, but I’d rather benchmark that properly before adding size/CPU heuristics.
I also went through trash-compactor after your comment and picked up a few useful ideas from it, so thanks for pointing me at it.