Gracefully handle non-writeable directory by using a default fallback path #500
Comments
|
As I noted in the other ticket about the beta with the ACE 2.x stuff in it: when I try to create an archive in a dir without write access, the app just crashes. So, I would not have seen that behavior being added. :-) The logs I linked to include that crash. That archive of logs is toward the (present) end of #402. |
|
I will double check then with the logs. This feature was developed just a two weeks ago so you're in fact one of the first to try it. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Did anything come up in the logs? I did try the dev version you pointed me to a couple of weeks ago, but it still hung when switching out of the application (in macOS 10.13.6), so I wasn't able to test much with it. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
@Darklocq did you had the chance to try the betas in another machine with 10.14? |
|
@Darklocq finally reproduced the hang. I'm looking for a fix now. |
|
As noted in other thread: I don't have another machine on which to run 10.13, nor any machine on which to run 10.14+ (my Mac will not do 10.14 without a hardware upgrade). I've downloaded 1013, and will give it a shot. Curious what you did to reproduce the issue (which for me is 100% - there must be some major difference between my setup and your usual one!) |
Really did nothing different... Not sure why was unable before, now its 100%. I'm using a Parallels VM.
Let me know when you have the chance :) |
|
https://www.youtube.com/watch?v=AXwGVXD7qEQ I've got it doing three compressions at once, and am able to leave and re-enter the app, add other jobs, change the preferences, etc., and it's all keeping to a reasonable CPU and RAM usage level. |
|
I would close this, but this was originally opened about fallback paths and handling of non-writeable directories; I'm not sure what the disposition of that matter was. |
|
@Darklocq the fallback system was already implemented, just now added the GUI (in Preferences - File Access) to customize the path. You can check it in this build: https://github.com/aonez/Keka/releases/download/dev-test-builds/Keka-fallback.7z |
|
Released in the latest dev build: v1.2.0-dev.3901 |
When extracting files or creating a new archive, Keka seems to just fail if the current directory is not writable by the user. Using a recent beta version (the one with ACE 2.x support), the app actually just crashed. (I included a crash log from that in the upload for the other ticket, about that beta).
I would suggest that what it should really do is save out to a pre-defined location,
~/Desktop/by default, but configurable as a preferences option. Some apps that do this sort of fallback saving use~/Downloads/, and others use~/Documents/or~/Documents/App_name_here/or whatever, and people may want to adjust Keka's fallback path to match whatever they're used to their other tools doing, and/or to mesh into some other workflow like a directory-watching app, or whatever. User choice is generally a good thing, while the user's desktop is a pretty typical default location for things, both in Mac and in Windows.Ideally, Keka would report that it has done this and why, e.g. "
Filename(s)saved to/The/Fallback/Path/because/The/Original/Directory/was not writable."The text was updated successfully, but these errors were encountered: