Quote:
Originally Posted by BetterRed
As I read it, the patch issues a warning message when a read-only file is opened, if the user's intent is to change the file and save in place then they should quit the editor and remove the RO permission before trying to edit.
|
Sure! My bad! I haven't seen the name of the modified method... and have interpolated as my wishes were :-)
Anyway, if I may give my advice, it's not an expected behavior to change the RW rights when we want to write on a protected file, and I guess that's what Falsifier is complaining about. If a book have been put in RO, calibre shouldn't overpass this decision, he could, maybe, only save after a warning, but without changing the permission (as vim do).
In fact, the expected behavior, IMO, would be to deny "save" on a RO only file, maybe with a warning saying why and suggesting either to change the perms or to "save a copy". But I guess it's not an easy task in the code (I understand that "save" and "save a copy" use the same method applied on different paths, so maybe it's not that simple to have a different behavior for one or for the other).
Quote:
Originally Posted by JSWolf
There's no reason to desist. [...] But if I was editing to make changes and it came up with a warning, I'd exit the editor and deal with the problem.
|
Yes, that's what's I have done, I didn't remember, but when I red the thread, I see I have finally saved my work. From my posts of feb. 2022:
Quote:
When an epub is read-only, the action "Save" fails, which is logical.
What is not expected is that the action "save as" also fails. Is it normal ?
[...]
No, /data/temp/ is 777.
In fact, giving w/r permission to the original epub (and no other action) solves the case and I can "save a copy" (perms of /data/temp/ didn't change)
That's why I presume that the permission of the destinatary dir. (w/r) is mixed up with the permission of the original file (w/o)
|