GNOME Bugzilla – Bug 574376
Save doesn't always save
Last modified: 2009-03-18 08:07:59 UTC
Please describe the problem: When trying to exit, without saving first, any changes are detected correctly, and the save dialog appears. It seems however, that pressing 'Save' doesn't save correctly. Steps to reproduce: 1. Open an existing file 2. Modify the file typing a couple of letters 3. Click on the 'close' (X top right) button 4. The Save dialog appears - click on Save Actual results: The last changes are _not_ saved. After reopening, the changes are not there Expected results: Find the last changes on disk Does this happen every time? Yes Other information:
Thanks for reporting. I can imaging that this happens because the "saver" object is destroyed before saving finishes. I will have a look this weekend! I guess you are using the gtksourceview editor?
Yes. Sorry, I should have mentioned that. I guess this could be the reason for the infrequent crashes on exit too? Didn't report that because it happens only once a week or so. GtkSourceView works quite well. There's only one thing I really hate: When copying the 'old' way, with just the mouse (paint + middle button paste), the cursor always jumps back to the original location, which is very annoying. But I guess I'll have complain to the GtkSourceView people about that. John
I made some changes but I cannot reproduce the bug here. I would be great if you could retry this with latest trunk. Thanks!
I updated to svn 4852, and no change. I tried several times, and, as documented before, the 'Changed' dialog appears, but clicking on 'Save' doesn't do it. It would be less annoying if a 'Save All' option would exist under 'Files'. After editing several files, the only way to assure saving is go to each and save them one by one. The following warnings do come out (I believe they weren't there before) on the console: (anjuta:13848): Gdl-WARNING **: Should not reach here: gdl_dock_select_larger_item:1132 (repeats 4 times). There is also this warning, but it _was_ there before. I suspect it's because I have no macros defined: I/O warning : failed to load external entity "/root/.local/share/anjuta/macro.xml" John
Hmm, I cannot reproduce this here and the warnings look really unrelated. BTW, there is a "Save all" option in the "Documents" menu.
I can reproduce this with SVN trunk.
(In reply to comment #1) > I guess you are using the gtksourceview editor? The problem appears to be present only in the GtkSourceView editor. The Scintilla editor did not pose any problems.
The asynchronous write (ie. g_output_stream_write_async) in sourceview_io_save_as is the problem here. Anjuta exits before the on_save_finished callback gets invoked. Using a blocking write (ie. g_output_stream_write) solves the problem.
Ah ok, sorry. I though you were refering to clicking on the "Close"-Button of an editor and not exiting the whole application. Hmm, that's indeed a bit tricky because we want async write operations of course as anything else would block the UI unnecessary long. I will try to think of a solution for it.
Anjuta takes 5 - 6 seconds to load on my machine. On exit, I wouldn't mind waiting for 1/2 second to be sure _all_ the source files are safely stored on disk. In fact, thinking back, this behaviour explains why I had entire swatches of source code disappear earlier. It's amazing how much you can type in 10 minutes between autosaves. How about the suggestion to change the behaviour of the 'Save' toolbutton, to make it save all changes (or add another one)? Even Turbo C/Pascal had a Save All option.
> How about the suggestion to change the behaviour of the 'Save' toolbutton, to > make it save all changes (or add another one)? Even Turbo C/Pascal had a Save > All option. As I said in comment #2, this option exists in the Documents menu (or with the shortcut Shift-Ctrl-L). Anyway, I am working on solving the issue by flushing all buffers but I couldn't figure out how to do this yet. Time is limited until Monday but I hope to be able to fix it before 2.26.0.
> As I said in comment #2, this option exists in the Documents menu (or with the > shortcut Shift-Ctrl-L). I humbly apologize for missing that. This is one of those weeks. University started again, 7 more hours of teaching, a utility transformer blew up and so did my UPS, fax, phone, and scanner. Still repairing... I would have expected file related commands to be under 'File' though. Thanks, John
Not that I am in favour of using blocking I/O calls, but it looks like the Scintilla editor plugin uses g_output_stream_write_all in the save_to_file function at plugins/scintilla/text_editor.c:1556 I was looking at how GEdit handles this, and found that they iterate through a list of files, and once the asynchronous write completion callback for the last file is invoked a signal is emitted to close the application.
Created attachment 130702 [details] [review] Finish all save operations before exit(1) This patch fixes the issue by waiting for all async operations that are propagated by anjuta_shell_saving_push/pop() before exiting. Asking for release-team approval...
Any chance for a 2.24.x release with this fix?
Thanks Johannes, applied the patch, recompiled - works fine. I feel a lot safer! John
(In reply to comment #15) > Any chance for a 2.24.x release with this fix? > No, I don't think so. We will release 2.26.0 on Wednesday and this will be our new stable series. If you need to maintain 2.24.x for other reasons in your distribution you can backport the patch and apply it to your package. (If you have problems with backporting I can have a look, too).
Created attachment 130705 [details] [review] Cleaned patch The last patch contained some unrelated changes in the git plugin and in the htdocs that were unintended. This patch is now clean though it still contains the move from GOutputStream to g_file_replace_contents_async because I think that this is useful. Thanks John for testing though this is 100%-reproducible for me without the patch!
Minor issue: +/** + * anjuta_shell_saving_push: + * @shell: A #AnjutaShell interface + * + * Decrease the count of files that need to be saved + * + */ +void anjuta_shell_saving_pop (AnjutaShell* shell) The comment should be 'anjuta_shell_saving_pop'.
(In reply to comment #18) Isn't g_cond_* a better way of doing this?
No, a GCond could help if we were using multiple threads. It's a gio implementation details how it does the async io - we just know when it's finished and this is all done within the main loop (in the main thread) when the "finished" signal is emitted. You can see in the patch that I don't use a mutex for the save_count because it's only accessed by one thread. I kind of thought that there might be a method to ask gio to finish all async operations but that doesn't seem to exist.
Created attachment 130767 [details] [review] Backport to 2.24.x
(In reply to comment #21) > No, a GCond could help if we were using multiple threads. It's a gio > implementation details how it does the async io - we just know when it's > finished and this is all done within the main loop (in the main thread) when > the "finished" signal is emitted. Okay, I had the wrong idea that the callback would get invoked from a separate thread. Could you please have a look at the backported patch against 2.24.x?
Looks good - were there any changes besides line numbers?
(In reply to comment #24) > Looks good - were there any changes besides line numbers? sourceview-io.c seemed to have some changes over the 2.24.x version.