Bug 202099 - gedit destroys ACLs/SELinux context/xattrs when saving files
Summary: gedit destroys ACLs/SELinux context/xattrs when saving files
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gedit
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
: 202097 (view as bug list)
Depends On:
Blocks: xattrs-tracker
TreeView+ depends on / blocked
 
Reported: 2006-08-10 19:33 UTC by James Antill
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-08-21 02:22:25 UTC
Type: ---
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 350805 0 Normal RESOLVED gedit destroys ACLs/SELinux context/xattrs when saving files 2020-10-31 16:48:10 UTC

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


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