GNOME Bugzilla – Bug 320688
EOG can overwrite readonly files
Last modified: 2011-10-30 16:30:28 UTC
Version details: 2.12.1 Somehow EOG can overwrite readonly files. To repro: 1. Save an image to the Desktop use change the permissions to 400 (read only) 2. Open another image in EOG 3. Click File -> Save As 4. Locate and select the image you previously saved to the desktop and click Save 5. At the Overwrite confirmation, click Overwrite. Results: File is overwritten Expected: Error is shown saying that the file is readonly. File is not overwritten.
Maybe should be a warning (default to "do not overwrite") not an error. It's perfectly legitimate (conceptually and in a general "legal unix" sense) to overwrite a file in this manner, even though it's something that is often surprising to new users.
I think it makes sense to be able to overwrite a file which you don't have permission to write to. I think the point is that the behaviour _shouldn't_ be suprising to users (even if it is possible using command line tools).
I confirm this in EOG 2.13.x. Maybe we should just warn the user the file is readonly (gedit does this). So, (s)he can choose to continue or not.
Created attachment 63702 [details] [review] Proposed patch
Attaching a patch which does the below: 1. Displays a "Overwrite Confirmation dialog" if: - File is read-only - The user owns the file. The file will be overwritten if user selects "Overwrite" option. 2. Displays an information dialog if: - File is read-only - User is not the owner of the file. This dialog mentions that user is not the owner of the file and hence cannot overwrite the read-only file.
I (again/still) disagree with situation #2 in comment #5. Why not follow the same standard of unix file-permissions meanings as the whole rest of the world? In a collaborative environment, it's extremely common that one needs to write to files that one doesn't own.
Is there any plan to include this patch, or similar, into a future release? I noticed that the proposed patch is the same way Gimp works.
I think that if the OS allows users to overwrite files owned by someone else, EOG should let them do it. Asking for confirmation, just like in the case of read-only files, should be enough, IMHO.
Comment on attachment 63702 [details] [review] Proposed patch Patch obsolete (not using gnomevfs anymore and the saving code has changed a lot since then).
Created attachment 182279 [details] [review] Patch that makes EOG's save as behave similar to Gimps save as (when saving a -r-------- file) I took a look at the Gimp's current method for handling read only files, as well as EOG's current behavior (current being what is on my RHEL6 box... not current as in from version control). EOG (2.28.2) does not overwrite the file. I guess the program could chmod or rm then recreate the file (if you are the owner) to force a save. Gimp (2.6.9) seems to preset a failed to save file dialog. This patch brings "Save As" closer to the gimps "Save As" feature.
Created attachment 182280 [details] [review] Same as previous patch sans the stray newline I accidentally added
(In reply to comment #11) > Created an attachment (id=182280) [details] [review] > Same as previous patch sans the stray newline I accidentally added Wait this is fail. if (g_access((gchar *)file, W_OK)) { ?? Should be something like if (!g_access((gchar *)file, W_OK)) { ?? Still working on this, also adding the permission denied message to eog_window_cmd_save.
Created attachment 182284 [details] [review] This patch adds a permissions denied dialog to save and save as... and it works :-)
Just noticed that we fixed this with the patch from bug 615376 (meaning this is already shipping with eog-3.2.x). If an image is write-protected the user will be asked to SaveAs to a new location when he tries to save. This is IMHO better than gedit's approach which disables its standard "Save" action alltogether in this situation.