Bug 202099

Summary: gedit destroys ACLs/SELinux context/xattrs when saving files
Product: [Fedora] Fedora Reporter: James Antill <james.antill>
Component: geditAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: kmacmill
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-21 02:22:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 201088    
Attachments:
Description Flags
patch to add full xattr copying to gedit none

Description James Antill 2006-08-10 19:33:35 UTC 
Description of problem:
 gedit saves files via. the traditional method of:

x = open_tmp_file()
write_data(x)
rename_orig_backup();
rename_tmp_orig();

...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:
 always

Additional info:

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

1. You need to call:

autoconf
autoheader
automake

...in the %build, due to needing to link to libattr etc.
Comment 1 James Antill 2006-08-10 19:33:36 UTC 
Created attachment 133977 [details]
patch to add full xattr copying to gedit
Comment 2 Ray Strode [halfline] 2006-08-10 19:39:04 UTC 
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 19:39:16 UTC 
*** Bug 202097 has been marked as a duplicate of this bug. ***
Comment 4 Matthias Clasen 2006-08-12 00:21:47 UTC 
Also, would it be appropriate to give a similar treatment to 
g_file_set_contents()  ?
Comment 5 Ray Strode [halfline] 2006-08-12 05:11:32 UTC 
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 14:24:22 UTC 
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-21 02:22:25 UTC 
fixed in the gedit that is in rawhide