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 546482 - Support backups while replacing files
Support backups while replacing files
Status: RESOLVED OBSOLETE
Product: gvfs
Classification: Core
Component: sftp backend
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
: 581037 (view as bug list)
Depends on:
Blocks: 360400
 
 
Reported: 2008-08-05 21:41 UTC by jessevdk@gmail.com
Modified: 2018-09-21 16:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Preserves ownership patch (5.38 KB, patch)
2008-08-05 21:44 UTC, jessevdk@gmail.com
committed Details | Review

Description jessevdk@gmail.com 2008-08-05 21:41:37 UTC
Currently, the sftp backend does not try to preserve file ownership when replacing a file due to the way the replace is implemented (using a temporary file, and an atomic move of that 'new' file to the original file). In doing this, the ownership of the file might be changed which is bad.
Comment 1 jessevdk@gmail.com 2008-08-05 21:44:47 UTC
Created attachment 115937 [details] [review]
Preserves ownership patch

The attached patch tries to preserve ownership of the file by trying to set the uid/gid when the temporary file is created. When this fails, the fallback strategy is to truncate and write the original file. Although it's more secure to use the temporary file/ atomic replace strategy, the fallback truncate strategy at least preserves the ownership if a temporary file with the same ownership as the original file can't be created.
Comment 2 Christian Kellner 2008-08-06 14:13:47 UTC
Expect for some small whitespace issues the patch looks good to me. Thanks a bunch, again! (-: Keep them coming ...
Comment 3 Christian Kellner 2008-08-06 14:17:45 UTC
On a second though. Maybe we should only bother setting the uid/gid if its != my_uid and my_gid
Comment 4 jessevdk@gmail.com 2008-08-06 21:03:51 UTC
I don't think that's really important, because it is not guaranteed that creating a file will put it on my_uid/my_gid, and even if it does, the chown isn't likely to fail anyway.

I think a more important issue is the possibility of data loss when using the truncating strategy, but I think given that:

1. Locate file saving uses the same strategies
2. The truncate code path is a corner case
3. Failing during save and completely loosing your data is a corner case

the truncate fallback should go in
Comment 5 jessevdk@gmail.com 2009-01-02 14:23:14 UTC
Was this ever committed?
Comment 6 Chuck Randall 2009-01-10 18:53:01 UTC
This looks related to the issue I'm having with saving files over sftp thru gedit.  How do I go about installing that patch?
Comment 7 Alexander Larsson 2009-02-16 11:14:10 UTC
What I don't like about this is that it totally breaks the backup making code.
I'm commiting this with an extra check so that it only triggers if !make_backup, but ideally we should handle this too by backing up before overwriting.
Comment 8 Alexander Larsson 2009-02-16 11:27:02 UTC
I changed the make_backup case to G_IO_ERROR_CANT_CREATE_BACKUP for now, but we should implement the backup code for that case too.
Comment 9 Fabio Durán Verdugo 2009-05-01 20:02:12 UTC
*** Bug 581037 has been marked as a duplicate of this bug. ***
Comment 10 Kjartan Maraas 2011-05-24 08:41:55 UTC
Should we mark the patch as needs-work or something else?
Comment 11 Tomas Bzatek 2011-09-08 16:15:04 UTC
The patch has been already committed on 2009-02-16 (commits 6543cd5ebf6d8, 	7178c101038be) but the comment 8 still stands.
Comment 12 GNOME Infrastructure Team 2018-09-21 16:24:34 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/55.