Bug 202099 - gedit destroys ACLs/SELinux context/xattrs when saving files
gedit destroys ACLs/SELinux context/xattrs when saving files
Product: Fedora
Classification: Fedora
Component: gedit (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
: 202097 (view as bug list)
Depends On:
Blocks: xattrs-tracker
  Show dependency treegraph
Reported: 2006-08-10 15:33 EDT by James Antill
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-20 22:22:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to add full xattr copying to gedit (3.18 KB, patch)
2006-08-10 15:33 EDT, James Antill
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 350805 None None None Never

  None (edit)
Description James Antill 2006-08-10 15:33:35 EDT
Description of problem:
 gedit saves files via. the traditional method of:

x = open_tmp_file()

...but it doesn't copy the xattrs from the orig. to the tempfile, so ACLs,
xattrs and SELinux context info. is all lost.

Version-Release number of selected component (if applicable):
 current rawhide, FC5

How reproducible:

Additional info:

 I've created a patch for gedit which fixes this.

1. You need to call:


...in the %build, due to needing to link to libattr etc.
Comment 1 James Antill 2006-08-10 15:33:36 EDT
Created attachment 133977 [details]
patch to add full xattr copying to gedit
Comment 2 Ray Strode [halfline] 2006-08-10 15:39:04 EDT
Hi James,

we can apply this locally in rawhide, but would you mind filing the patch
upstream as well?
Comment 3 Karl MacMillan 2006-08-10 15:39:16 EDT
*** Bug 202097 has been marked as a duplicate of this bug. ***
Comment 4 Matthias Clasen 2006-08-11 20:21:47 EDT
Also, would it be appropriate to give a similar treatment to 
g_file_set_contents()  ?
Comment 5 Ray Strode [halfline] 2006-08-12 01:11:32 EDT
Well, we document g_file_set_contents as explicitly not having those semantics:

"On Unix, if filename already exists hard links to filename will break. Also
since the file is recreated, existing permissions, access control lists,
metadata etc. may be lost. If filename is a symbolic link, the link itself will
be replaced, not the linked file."
Comment 6 Matthias Clasen 2006-08-12 10:24:22 EDT
Well, we say it _may_ be lost. We don't say it _will_ be lost. Looks like a
quality-of-implementation issue to me.
Comment 7 Matthias Clasen 2006-08-20 22:22:25 EDT
fixed in the gedit that is in rawhide

Note You need to log in before you can comment on or make changes to this bug.