GNOME Bugzilla – Bug 312930
Problems with save to file owned by others in "t"-mode directory
Last modified: 2005-08-09 16:07:56 UTC
Version details: 1.4.3 as in Debian Sarge Distribution/Version: Debian Sarge a directory, owned by root, group users, group writable, with a file owned by somebody else, also group writable drwxrws--T 12 root users 4096 2005-07-31 22:08 .. -rw-rw-r-- 1 marin users 2696 2004-11-04 23:30 testfile.gnumeric I am in group users, so I can write that file. Already twice, I opened the file, and discovered that several tabs were missing that were present previously. It seems that gnumeriv creates backup files, because the directory is filled with files likle these: -rw------- 1 olivier users 4681 2005-08-07 21:24 .gsf-save-1buSb3 -rw------- 1 olivier users 5116 2005-08-07 22:03 .gsf-save-80FeKf -rw------- 1 olivier users 4489 2005-08-07 21:18 .gsf-save-BhUEWy -rw------- 1 olivier users 5198 2005-08-07 22:07 .gsf-save-CDs7SG -rw------- 1 olivier users 4008 2005-08-07 21:07 .gsf-save-F3Dtfw luckily one of these backup files had all the information that was previously in the file. But losing data is not so nice.....
Gnumeric always writes to a temporary file, then renames that on top of the target after the complete save. The ".gsf-save-*" files are those. 1. You ought to get an error message for the save? Do you? 2. The target file ought to be unchanged. Is it? You can simply rename the .gsf stuff to foo.gnumeric and your data ought to be intact.
1) I do not get any error messages 2) the target file is unchanged indeed BUT: I do have write permission on this file !!!! So I should be capable of writing to it!
We are probably going to refuse to write to the file, but we clearly should not do so silently. It's a tradeoff: yes, the file is writable for you so we could write to it directly, but if something happened during the save (crash, disk full, whatever) you would have neither the original file nor the new. Tossing to libgsf whose fault it really is. (Same people.)
for Bluefish we used to have a similar approach, but we've changed it. Now the original file is copied to <filename>~ (copied, not moved, otherwise the permissions and owner of the original file would change, because we would re-create that file), and then Bluefish starts to write data in the original file. This behavior is what people expect, permissions on the file are effective, and still a backup is created first, before trying to write the new file.
Well, that does not work when the file is not readable. And it changes owner and group on the backup file. Emacs -- which is a very old program -- has lots of settings for what different users want. That's an indication that there are no simple solutions that will make everyone happy. (But, no, I am not going to copy Emacs 99 settings.)
that is correct, however, writing to a file for which you have no read rights is not a very common situation. Writing to a file for which you have write access but no delete access is a much more common situation. a solution to the problem would be to fall back to copy if rename is prohibited. So first use rename, and only if that fails, use copy. This will keep the same behavior for most people, but will fix the issue described in this bugreport. I guess that would make most people happy.
The immediate problem -- that the save silently failed -- has been fixed in cvs HEAD (libgsf and gnumeric). The process now produces an error message. We'll keep the t-mode-directory issue as well as the related ro-directory issues in mind.