Open eject-it opened 9 years ago
/cc @nathansobo
This looks like it's actually an issue with creating backup files in write-protected directories. We should probably check that we have permission before attempting to create one. As a workaround you can disable backup before saving when editing in these kinds of situations.
How about declaring a backup directory? obviously there would need to be a few check involved as well. Otherwise it might attempt creating a copy of some ridiculously large file, probably binary, that was opened by mistake.
How about declaring a backup directory?
That could work, although part of the value of this simple implementation is that if something goes wrong, your backup file is sitting right next to the original with a ~
appended to it and is easy to find. If we go to a backup directory, we may need to implement a command like recover-from-backup
or something to help people.
[Enter steps to reproduce below:]
And poof, there it goes. Will work everytime. It isn't really the fault of the autosave package. It is Atom itself that is not capable of dealing with write protected files. You can't save them elsewhere even when no autosave is being used it won't let you choose another destination. Why it brings up the password dialog in the first place is beyond me anyway. Even if I enter my sudo capable password it will not be able to edit a file of the type that has the write privs at 0 (like 600, 700, 400 whatever). It would propably need a privileged helper tool for that. System: Mac OS X 10.10.5 Thrown From: autosave package, v0.22.0
Stack Trace
Uncaught Error: Can't create a backup file for /usr/local/texlive/2015/texmf-dist/tex/latex/xcolor-solarized/xcolor-solarized.sty because files already exist at every candidate path.
Commands
Config
Installed Packages