Launchpad has imported 4 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=508489.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2009-06-27T19:34:54+00:00 Vladimir wrote: Description of problem: When saving an image, eog does not retain the original permissions and ownership. Version-Release number of selected component (if applicable): eog-2.24.3.1-1.fc10.i386 How reproducible: Do a modification to an image in eog and save it. Steps to Reproduce: 1. Open image in eog 2. Rotate the image 3. Save the image (File->Save) Actual results: The original permissions are gone. Expected results: The permissions should be retained. Additional info: This is painful for multi-user system or file server because it blocks other users from accessing the file. In my case the original file attributes looked like this: rw-rw-r--+ 1 myuser mygroup After eog saved the image (in place) the attributes changed to: rw-rw-r--+ 1 myuser myuser My umask (when run in terminal) is 0002. It seems this is caused by the way how eog performs the modification and save; strace output releals the following: [pid 8643] lstat64("/tmp/eog-save-F87BWU", {st_mode=S_IFREG|0600, st_size=42043 7, ...}) = 0 [pid 8643] lstat64("/var/tmp/bio.jpg", {st_mode=S_IFREG|0664, st_size=409310, . ..}) = 0 [pid 8643] rename("/tmp/eog-save-F87BWU", "/var/tmp/bio.jpg" <unfinished ...> [pid 8638] <... poll resumed> ) = 1 ([{fd=15, revents=POLLIN}]) Reply at: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/792145/comments/0 ------------------------------------------------------------------------ On 2009-06-27T19:36:41+00:00 Vladimir wrote: Created attachment 349670 strace output of eog process which rotates and than saves an image Reply at: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/792145/comments/1 ------------------------------------------------------------------------ On 2009-11-18T10:04:38+00:00 Bug wrote: This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/792145/comments/2 ------------------------------------------------------------------------ On 2009-12-18T09:36:05+00:00 Bug wrote: Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. Reply at: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/792145/comments/3 ** Changed in: eog (Fedora) Status: Unknown => Won't Fix ** Changed in: eog (Fedora) Importance: Unknown => High -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/792145 Title: eog (Eye of Gnome) ignores umask settings Status in Eye of GNOME: Fix Released Status in eog package in Ubuntu: Fix Released Status in eog package in Fedora: Won't Fix Bug description: Binary package hint: eog This does not seem to be a generic Gnome or gnome-vfs bug (some similar bug reports exist for earlier Ubuntu releases), I have only been able to reproduce it in eog. Expected Behavior: Rotating an image and saving it should not change / break group permissions on the file. Expect that eog will respect system umask settings in the same way that other Gnome applications do. What Happens: Rotating an image and then clicking "Save" changes the permission so only the owner has read/write, all group permissions are removed. eog seems to be hard-coded to a specific umask rather than respecting the system configuration. This breaks group access to image files that have been rotated by other members of a group. To reproduce: 1. Change system umask from default (probably 022) to 002 (I am not exactly sure of minimum needed to do this, I added "umask 002" to a dozen files before realizing that the bug was only in eog, not a generic Gnome issue. 2. Open an image in eog. Rotate the image. Save the image. 3. Observe that the group permissions on the file are now gone (e.g. only owner has rw). More detailed instructions: 1. Change system umask settings, reboot [NOTE: what is official minimum method for setting umask for Gnome apps?]. Confirm current system umask settings and the umask used by Gnome apps $ umask 0002 $ touch picture.txt $ nautilus Create an empty file using File--> Create Document--> Empty File [I called the new file picture.empty] May need to chmod some group permissions before performing the test. In this case, we use an existing image file named picture.jpg $ chmod g+rw picture.jpg $ chmod o+r picture.jpg $ ls -al picture* -rw-rw-r-- 1 dan 5000 0 2011-06-02 20:37 picture.empty -rw-rw-r-- 1 dan 5000 1395326 2011-06-02 20:15 picture.jpg -rw-rw-r-- 1 dan 5000 0 2011-06-02 20:31 picture.txt Notice that group has rw permission on the newly created files (touch and Nautilus respect umask setting). 2. Open the image file in Eye of Gnome. $ eog picture.jpg Rotate the image, Save the image. Close eog. 3. The file permissions have changed, group permissions are gone, and the permission do not match those of newly created files from other Gnome apps such as Nautilus. $ ls -al picture* -rw-rw-r-- 1 dan 5000 0 2011-06-02 20:37 picture.empty -rw------- 1 dan 5000 1395718 2011-06-02 20:43 picture.jpg -rw-rw-r-- 1 dan 5000 0 2011-06-02 20:31 picture.txt ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: eog 2.30.0-0ubuntu1 ProcVersionSignature: Ubuntu 2.6.32-31.61-generic 2.6.32.32+drm33.14 Uname: Linux 2.6.32-31-generic x86_64 Architecture: amd64 Date: Thu Jun 2 20:06:12 2011 ProcEnviron: LANG=en_US.utf8 SHELL=/bin/bash SourcePackage: eog To manage notifications about this bug go to: https://bugs.launchpad.net/eog/+bug/792145/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
