After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 468578 - gedit changing permissions and owner of every file it touches.
gedit changing permissions and owner of every file it touches.
Product: gedit
Classification: Applications
Component: general
Other All
: Normal normal
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Reported: 2007-08-20 16:29 UTC by G. Michael Carter
Modified: 2008-09-02 16:07 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20

Description G. Michael Carter 2007-08-20 16:29:30 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?

Other information:
Comment 1 jake 2007-10-07 13:57:22 UTC
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.
Comment 2 Sebastien Bacher 2007-10-17 13:10:59 UTC
There is a similar bug on

"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
Comment 3 Paolo Borelli 2007-10-17 17:11:29 UTC
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)
Comment 4 vanadium 2008-09-02 08:18:51 UTC
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 ( 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~

**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~
Comment 5 2008-09-02 16:07:49 UTC
This is actually a gvfs bug, for which a report has been filed in bug #546482