Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
This app silently produces broken files any time it hangs or crashes on a compression or decompression option, because it's writing directly to the final filenames. Most of the good zipping apps I use (on Mac or Windows) do not do this, but write to a temp file then move the result(s) to the final file name(s) after the app is certain it was done properly. This is really the only way to be sure that either a compressed archive is complete and not corrupt, and that extracted files are not truncated or otherwise mangled. When an app crashes or hangs, too often we cannot really tell (e.g., the Notification Center pop-ups do not last long). The only other archive apps I had that wrote directly to the final filenames also had this "Well, I can't really tell if this file is legit" problem, and I had to quit using them (e.g. The Archive Browser, the modern fork of which, The Unarchiver, now uses temp files).
Fixing this would also make the app more scriptable. For example, if I know from one tool or another what files an archive contains, I can then auto-move the extracted results from Keka based on their extensions (or whatever) and have some confidence that I'm not doing something terrible like moving broken chunks of MP3s into my music library.
Apps use multiple approaches to this kind of temp file operation. One common way is to do something like
I vastly prefer the first, simplest approach because 1) the KISS principle; 2) it's visible, right where you are working, and without turning on "hidden files" features; and 3) it doesn't create bogus filename.ext files that other tools (including the OS itself) can mistake for complete, valid files.
Finally, the app should check for such detritus after a crash/hang and remove it. I suppose it could keep a record of what temp files it is using, and just make sure they are not laying around, either after a job completes successfully, or when the app is restarted after a crash, hang, force quit, loss of system power, user cancellation of a operation, etc.
@Darklocq current stable versions already use a temporary folder for extractions (developed back in 2010) called .Keka-XXX. Once the extraction is done the files inside are moved to the final destination. If the operation fails this folder is deleted. If Keka crashes this folder is removed the next time Keka is properly closed.
As for compressions I wish it was so simple. Due to sandbox limitations, if Keka has no file access to a folder it can only read/write the file specified in the save panel. So if you choose to compress some files in your Desktop at "files.7z", Keka can only write this file, not "files.7z.ktmp".
So maybe I can enhance the compression like this process:
Sounds like a reasonable approach. I wasn't aware of that sandboxing problem. Honestly, I've turned off most of Apple's security paranoia, as I'm careful about what I use and from where, and also use various layers of firewalls and anti-malware and so on. So I might not have encountered some of the "you can't normally do that" issues myself. I'm a Linux guy when it comes to dev work, so I don't know what to expect when it comes to macOS "gotchas". I just disable things like GateKeeper and SIP that get in the way of me using my machine as I see fit.
PS: I believe that the current, commercial version of The Unarchiver (by MacPaw) is subject to a requirement to release the source, because it is based on the original The Unarchiver and The Archive Browser (MIT License), in turn based on previous material released under LGPL. However, its Google Code repo hasn't been updated in over 4 years, and the more recent BitBucket repo has vanished. I've asked MacPaw for a working source repo, so the app's sandboxing behavior can be examined. The available repos for the pre-commercial The Unarchiver and The Archive Browser are probably too old to be relevant (I think they pre-date this macOS sandboxing stuff).