GNOME Bugzilla – Bug 546482
Support backups while replacing files
Last modified: 2018-09-21 16:24:34 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.
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.
Expect for some small whitespace issues the patch looks good to me. Thanks a bunch, again! (-: Keep them coming ...
On a second though. Maybe we should only bother setting the uid/gid if its != my_uid and my_gid
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
Was this ever committed?
This looks related to the issue I'm having with saving files over sftp thru gedit. How do I go about installing that patch?
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.
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.
*** Bug 581037 has been marked as a duplicate of this bug. ***
Should we mark the patch as needs-work or something else?
The patch has been already committed on 2009-02-16 (commits 6543cd5ebf6d8, 7178c101038be) but the comment 8 still stands.
-- 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.