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

Gracefully handle non-writeable directory by using a default fallback path #500

Open
Darklocq opened this issue Dec 12, 2019 · 5 comments
Open
Assignees
Labels
Milestone

Comments

@Darklocq
Copy link

@Darklocq Darklocq commented Dec 12, 2019

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

@aonez

This comment has been minimized.

Copy link
Owner

@aonez aonez commented Dec 12, 2019

Thanks again @Darklocq! This was already suggested here #183. I've added the notification idea and the customization of the path there.

The actual fallback was already implemented in the ACE beta, it uses the Desktop as a fallback. Is not working for you in that beta?

@aonez aonez self-assigned this Dec 12, 2019
@aonez aonez added the duplicated label Dec 12, 2019
@aonez aonez added this to the 1.2.0 milestone Dec 12, 2019
@Darklocq

This comment has been minimized.

Copy link
Author

@Darklocq Darklocq commented Dec 12, 2019

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.

@aonez

This comment has been minimized.

Copy link
Owner

@aonez aonez commented Dec 12, 2019

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.

@stale

This comment has been minimized.

Copy link

@stale stale bot commented Jan 4, 2020

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.

@stale stale bot added the stale label Jan 4, 2020
@Darklocq

This comment has been minimized.

Copy link
Author

@Darklocq Darklocq commented Jan 6, 2020

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.

@stale stale bot removed the stale label Jan 6, 2020
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.