GNOME Bugzilla – Bug 92896
gedit won't save file in some instances
Last modified: 2009-11-22 19:22:54 UTC
Package: gedit Severity: normal Version: 2.0.2 Synopsis: gedit won't save file in some instances Bugzilla-Product: gedit Bugzilla-Component: general Description: Description of Problem: If you own a file, and that file is in a directory for which you don't have write permission, gedit will not let you save your changes. Steps to reproduce the problem: 1. Find a directory that you don't have write permission in, but that you can access (i.e. /usr/local/bin). 2. As root, touch a file and chown it to yourself (or chown an existing file). 3. As yourself: open this file in gedit, make some changes and then hit "save". Actual Results: An error box will pop up saying 'could not save the file "xxxxxx"'. Expected Results: You should be able to save the changes to the file. How often does this happen? Every time. Additional Information: If you make the directory writeable to yourself, then you can save the document - no surprises there I guess. This does seem to be specific to gedit, not to the filesystem, since I can open the same file in nedit and it can save changes. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-09-09 20:09 ------- Reassigning to the default owner of the component, maggi@athena.polito.it.
Confirming with 2.0.5. This may be gnome-vfs?
No, it is not a gnome-vfs problem since we are not using it for saving files.
This is due to the way gedit saves files. ATM, it needs that the file directory is writable since it saves a temp file in the directory. If a backup file has to be created, then the original file "test.txt" is renamed "test.txt~". Finally, the temp file is renamed "test.txt" (ad the original howner and permissions are restored). I don't see an easy way to fix this bug using the current algorithm. Probably we should change the algo we are using but we should be very careful in order to do not have regressions on other old problems. Federico: Any idea? A part from "Man, Unix sucks" :-)
I am currently working on a fix for this bug. I'll post a patch hopefully within the next couple days.
What nedit does under these circumstances - when it discovers it can't save the backup version of the file - is to notify the user that "the backup file cannot be saved, so for this session backups are now disabled" (or words to that effect). So you can still save your changes to the existing file, but there's no fall-back in that instance.
Ok, I like the nedit behavior, i.e. we should tell the user that gedit is not able to create the backup file and ask her if she wants to save the file anyway. Matt: please note that gedit-document is a non-GUI class, so you need to manage this problem using exceptions (i.e. GError). Have you thought about using gnome-vfs to save files? You should be able to find a preliminary patch on the gedit mailing list. Thanks.
Matt: are you still working on it?
Yes, I am. I'll have an initial patch soon. I'm also addressing the issue of backups for special files (e.g. links) and files owned by other users -- these can't safely be backed up by renaming the original file, because their attributes cannot be preserved. I'm planning to emulate the default "backupcopy=auto" behavior of the Vim editor: http://vimdoc.sourceforge.net/cgi-bin/vim2html2.pl?page=options.txt#'backupcopy' That page has a good discussion of the issues. Hopefully in the long run we can get some of this code into a gnome-vfs API, so that each app doesn't have to reinvent it.
Status update: Still working on this. Fell behind a bit because it takes a long time for my computer to download and compile the GNOME 2.1.0 libraries now required for CVS gedit.
Matt: any news?
No, sorry -- I haven't had much time for hacking and have had trouble keeping up with Gnome 2.1 CVS. I may pick this up again in a few weeks, but for now if someone else wants to work on it please go ahead.
No, still not working on this, and no plans for it right now.
I couldn't access the vimtohtml discussion, and apologize if I am repeating what was said there. The attempt to write the temp file could fail a) because the temp file name exists and is read only b) because the directory is read only One solution is to reset the edited file to zero length (equivalent to cat /dev/null > /usr/local/bin/fred.txt) and then write the file directly. This would preserve the file's flags. This runs the risk that a failure occurs and the user is left without the old or new versions of the file. To offset that one might try copying the original file somewhere else before updating it, e.g. cp /usr/local/bin/fred.txt > ~/.gedit/backup/fred.txt and now write new data to /usr/local/bin/fred.txt mv's don't work if the directory is read only but cat's do. by writing to the original file the flags are preserved. I would recommend informing the user where the backup of the original file has been placed and why it couldn't have been placed at the usual location.
From VIM documentation: 'backupcopy' 'bkc' string (Vi default for Unix: "yes", otherwise: "auto") global {not in Vi} When writing a file and a backup is made, this option tells how it's done: "yes" make a copy of the file and overwrite the original one "no" rename the file and write a new one "auto" one of the previous, what works best Making a copy and overwriting the original file: - Takes extra time to copy the file. + When the file has special attributes, is a (hard/symbolic) link or has a resource fork, all this is preserved. - When the file is a link the backup will have the name of the link, not of the real file. Renaming the file and writing a new one: + It's fast. - Sometimes not all attributes of the file can be copied to the new file. - When the file is a link the new file will not be a link. The "auto" value is the middle way: When Vim sees that renaming file is possible without side effects (the attributes can be passed on and and the file is not a link) that is used. When problems are expected, a copy will be made. One situation where "no" and "auto" will cause problems: A program that opens a file, invokes Vim to edit that file, and then tests if the open file was changed (through the file descriptor) will check the backup file instead of the newly created file. "crontab -e" is an example. When a copy is made, the original file is truncated and then filled with the new text. This means that protection bits, owner and symbolic links of the original file are unmodified. The backup file however, is a new file, owned by the user who edited the file. The group of the backup is set to the group of the original file. If this fails, the protection bits for the group are made the same as for others. When the file is renamed this is the other way around: The backup has the same attributes of the original file, and the newly written file is owned by the current user. When the file was a (hard/symbolic) link, the new file will not! That's why the "auto" value doesn't rename when the file is a link. The owner and group of the newly written file will be set to the same ones as the original file, but the system may refuse to do this. In that case the "auto" value will again not rename the file.
BTW, I think we should try to implement a simple solution (like the one used bu nedit) in time for gnome 2.2 and then starting discussing and implementing a more complex one (like the one used by VIM).
Okay, I have created a revised version of gedit-document.c that implements the nedit behavior. I haven't added an explicit warning to the end user though, as I suspect that it is perhaps too late for the translators. What do you think? I now need to find out how to send the revised file, presumably the gedit mailing list, no? I will check on #gedit
Created attachment 13620 [details] [review] revised to fix bug 92896 following behavior of nedit
I have attached the patched version of gedit-document.c The changes are to the function: gedit_document_save_as_real() It would benefit from a user warning message at or around line 1231, assuming we have time for this to be translated. I would be happy to work on supporting the vim behavior as part of the post 2.2 work. Regards, Dave Raggett
dsr: Please, use "cvs diff -u -p" to send patches.
*** Bug 111100 has been marked as a duplicate of this bug. ***
See also bug #104432 dsr: are you still willing to work on this bug for gedit 2.4?
Created attachment 17256 [details] [review] patch against CVS for nedit behavior
I know I was the reporter of this bug - about 15 months ago - but at this point I have no interest in any reports regarding this bug. There doesn't appear to be a way for me to remove my name via bugzilla. Could someone please reassign the "reporter" to a different address? Thank you.
Created attachment 27485 [details] [review] Works fine while saving changed file in a directory that doesnt have write permission, but belongs to the user When we are trying to save a changed file in a directory that doesnt have write permission, saving was not possible. This is because each time a file is changed, a new temporary file is created in the current directory. As the directory does not have write permission, an error indicating "cannot save "filename" was thrown to the user. In order to overcome this problem, whenever the directory doesnt have write permission, instead of creating a new file, the old file is copied to the temporary directory /tmp and then copied back to the file being edited. This solves the problem
Thanks for the patch. Note that I'm rewriting the "save" function in order to use gnome-vfs.
*** Bug 148039 has been marked as a duplicate of this bug. ***
Created attachment 33719 [details] [review] gnome-vfs based saving using auto backup strategy The error reporting needs working on. I've been using the code in screem for the past few days without problems, and its seems okay from quick tests in gedit.
Hi David, thanks a lot for taking the time to port the screem code against gedit, it's really appreciated. I know that Paolo Maggi has been working on the saving code, so I'll leave to him commenting on the patch and integrating it with his work.
David, thanks for the patch. I will review it ASAP.
Created attachment 33827 [details] [review] fixed version of vfs save patch This fixes a problem with the previous patch failing to save when backups are disabled.
Comment on attachment 27485 [details] [review] Works fine while saving changed file in a directory that doesnt have write permission, but belongs to the user We are going to rewrite the save function using gnome-vfs
Comment on attachment 33827 [details] [review] fixed version of vfs save patch Thanks for the patch, but we are completely rewriting the save_as_real function in order to implement a vim -like behavior (see our prototyped patch on bug #110191). We are trying to write the code in a gedit indepent way, so when finished you should be able to adopt it for screem if you would like.
I've just hit this bug, commandline steps to reproduce: nelson@gnelson ~ $ echo "testfile" > testfile.txt nelson@gnelson ~ $ su Password: gnelson nelson # mkdir /usr/share/testdir gnelson nelson # mv testfile.txt /usr/share/testdir/ gnelson nelson # exit exit nelson@gnelson ~ $ vi /usr/share/testdir/testfile.txt (vi *can* save the file) nelson@gnelson ~ $ gedit /usr/share/testdir/testfile.txt (gedit *cannot* save the file)
Nowadays it informs you of not being able to create a backup file, however it still allows you to save.
Can confirm what diego in comment 35 says. So mabybe the original issue (gedit won't save file in some instances) has been resolved?
Indeed, we have a fallback strategy now, which truncates the file. This is not as safe as writing the file to a temporary location, and then moving it over to the actual location, hence the warning you will see. I'm closing this bug as I consider the reported issue fixed.