GNOME Bugzilla – Bug 468578
gedit changing permissions and owner of every file it touches.
Last modified: 2008-09-02 16:07:49 UTC
Please describe the problem: Before editing with gedit [mcarter@snow-faerie class]$ ls -l GeoCaching.php -rw-rw---- 1 thecarte dba 102700 2007-08-20 12:19 GeoCaching.php after editing with gedit [mcarter@snow-faerie class]$ ls -l GeoCaching.php -rw------- 1 mcarter family 102700 2007-08-20 12:25 GeoCaching.php Steps to reproduce: just edit a file owned by another user Actual results: the owner and group name change to the default of the account. This creates havoc as it's changing preset permissions on files Expected results: nothing. Just save the file. Does this happen every time? yes Other information:
I have this same issue and it's very irritating. I like to edit my web pages with gedit, but it sets the permissions back to 600 so they won't be available to the public after the edit.
There is a similar bug on https://bugs.edge.launchpad.net/bugs/152638 "This is an issue that is introduced in Gutsy, but worked correctly in Feisty. Steps to reproduce the problem: enter following code in terminal, when gedit appears, type something, exit while saving. mkdir test; cd test; touch test sudo chown root:video test sudo chmod 660 test ls -l gedit test ls -l A normal user is by default member of the video group, and therefore can edit the file test. On Feisty, the permissions are correctly retained when the normal user has edited the file: -rw-rw---- 1 root video 5 2007-10-14 15:55 test -rw-r----- 1 vanadium video 0 2007-10-14 15:55 test~ However, two users of Gutsy report a different behaviour: -rw------- 1 rfb rfb 6 2007-10-13 19:32 test -rw-rw---- 1 root video 0 2007-10-13 19:31 test~ Indeed, the backup has the original permissions, but permissions and owner are changed for the edited version. This obviously cripples the concept of unix permissions and will result in eventual hard links to point to the backup file instead of the updated file. As far as my technical skills go, this must be no more than a gedit issue, where gedit now saves the new content in a new inode (renaming afterwards) instead of saving to the same inode, as it should to maintain the integrity of the file management." Confirmed using the new gedit 2.20.2
Damn... I should have looked into this bug earlier. Anyway it is an important fix and I'll release a gedit 2.20.3 unless anyone has objections. Note however that the bug will not affect hard links, it just affect the case where the user has write the directory but someonelse owns the file. The patch is a oneliner... Index: gedit/gedit-local-document-saver.c =================================================================== --- gedit/gedit-local-document-saver.c (revisione 5968) +++ gedit/gedit-local-document-saver.c (copia locale) @@ -417,7 +417,7 @@ save_existing_local_file (GeditLocalDocu gedit_debug_message (DEBUG_SAVER, "could not set perms"); /* Check that we really needed to change something */ - if (fstat (lsaver->priv->fd, &tmp_statbuf) != 0 || + if (fstat (tmpfd, &tmp_statbuf) != 0 || statbuf.st_uid != tmp_statbuf.st_uid || statbuf.st_gid != tmp_statbuf.st_gid || statbuf.st_mode != tmp_statbuf.st_mode)
This issue seems to persist for files on a remote file system. It came to my attention through a comment on the Ubuntu user forum (http://ubuntuforums.org/showthread.php?t=907512). The user edits files like sftp://user@host/var/www/.... I can confirm that the issue still exists for files on a file system mounted with sshfs. Gedit does write the updated file to a new inode, which eventually might cause owner and group to change. Another editor such as nano behaves correctly and writes the updated file data to the same inode. Following output demonstrates the issue. There is output from the client system, where a remote file system is mounted through sshfs. There is also output from "the server side" through an ssh session. **client side**** vanadium@laptop:~/mnt/remoteserver/PC/test$ touch test vanadium@laptop:~/mnt/remoteserver/PC/test$ ls -li total 0 42 -rw-r--r-- 1 12719 7090 0 2008-09-02 10:00 test vanadium@laptop:~/mnt/remoteserver/PC/test$ gedit test vanadium@laptop:~/mnt/remoteserver/PC/test$ ls -li #inode has changed total 4 43 -rw-r--r-- 1 12719 7090 10 2008-09-02 10:00 test 42 -rw-r--r-- 1 12719 7090 0 2008-09-02 10:00 test~ vanadium@laptop:~/mnt/remoteserver/PC/test$ nano test vanadium@laptop:~/mnt/remoteserver/PC/test$ ls -li #inode does not change total 4 43 -rw-r--r-- 1 12719 7090 16 2008-09-02 10:01 test 42 -rw-r--r-- 1 12719 7090 0 2008-09-02 10:00 test~ vanadium@laptop:~/mnt/remoteserver/PC/test$ **ssh session on server**** $ ls -li total 0 $ ls -li total 0 29009695 -rw-r--r-- 1 vanadium account 0 Sep 2 10:00 test $ ls -li ####after editing the file using gedit inode changes total 0 29009696 -rw-r--r-- 1 vanadium account 10 Sep 2 10:00 test 29009695 -rw-r--r-- 1 vanadium account 0 Sep 2 10:00 test~ $ ls -li ##### after editing with nano, inode does not change total 0 29009696 -rw-r--r-- 1 vanadium account 16 Sep 2 10:01 test 29009695 -rw-r--r-- 1 vanadium account 0 Sep 2 10:00 test~ $
This is actually a gvfs bug, for which a report has been filed in bug #546482