Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use temp files #499

Open
Darklocq opened this issue Dec 12, 2019 · 2 comments
Open

Use temp files #499

Darklocq opened this issue Dec 12, 2019 · 2 comments
Assignees
Milestone

Comments

@Darklocq
Copy link

@Darklocq Darklocq commented Dec 12, 2019

  • Save a bookmark where a compression will be stored (same as extractions)
  • Delete that bookmark if the operation finishes or the file is removed after a crash
  • Use a temporary name name.extension.ktemp if Keka has file access in the destination

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 filename.ext.keka_temp for an in-progress filename.ext. Another is to do something like .Keka_temp/filename.ext. And another is a somewhat messy combination approach, e.g., .filename.ext.keka_temp or .Keka_temp/filename.ext.keka_temp. An even more messy approach is to use something like ~/Library/Application Support/Keka/Temp/filename.ext.keka_temp or ~/Documents/Keka/Temp/filename.ext.keka_temp, which is stuff most of us would never notice or find.

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.

@issuelabeler issuelabeler bot added rar unar labels Dec 12, 2019
@aonez aonez added core enhancement sandbox and removed rar unar labels Dec 12, 2019
@aonez aonez self-assigned this Dec 12, 2019
@aonez aonez added this to the Look at milestone Dec 12, 2019
@aonez

This comment has been minimized.

Copy link
Owner

@aonez aonez commented Dec 12, 2019

@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:

  • Save a bookmark where a compression will be stored (same as extractions)
  • Delete that bookmark if the operation finishes or the file is removed after a crash
  • Use a temporary name name.extension.ktemp if Keka has file access in the destination
@aonez aonez modified the milestones: Look at, 1.2.0 Dec 12, 2019
@Darklocq

This comment has been minimized.

Copy link
Author

@Darklocq Darklocq commented Dec 12, 2019

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.