GNOME Bugzilla – Bug 758567
Anjuta shows "The file on the disk is more recent than the current buffer. Do you want to reload" every time upon saving
Last modified: 2017-06-25 13:30:06 UTC
Created attachment 316124 [details] Screenshot This happened apparently since the fix to bug#756426 made it to 3.18.2 apparently, but since then making any modification to a file and hitting Ctrl+S or clicking on Save results in anjuta popping up the message "The file [foo] on the disk is more recent than the current buffer. Do you want to reload? <Refresh> <Cancel>". This seems to be misleading though, because the only app that has modified the file is anjuta itself and hitting refresh only results in the anjuta reloading from disk the file only it had itself modified and saved just a few moments ago. In fact you can keep working through without caring for the message and no data is ever lost, so, this is really a nuisance and probably nothing more. Still, would be nice to see fixed.
Just to add, this happens _only_ when the file being edited has a backup (*~) in the dir, so e.g. if I were editing a file foo.cc that already had foo.cc~ file in the same dir (which anjuta itself creates btw) then upon saving the state of foo.cc this message would show up. If you remove the *~ file and then save, then it works fine. So looks like it might be in fact related to https://git.gnome.org/browse/anjuta/commit/?h=gnome-3-18&id=22ec0c212900d68e621cdf14281aa164a003d20a
Hi, I am having the same problem. Unfortunately, I have removed the *~ files like Atri suggested and disabled "create backup files" in the settings and I continue to have an issue. Having a quick look at the code, it appears (and I am no expert on gtk or the other libraries) that an asynchronous save is being completed [g_file_replace_contents_async()], but between the start of the save and the on_save_finished() callback the monitoring for the on_file_changed event is not disabled or being ignored between these events. Thus it appears that the file has of course changed .. we are saving it ourselves. But, I am by no means an authority -- please confirm my assumptions.
Has this ever been rectified? (I have checked the following editions, but did not find any references) It basically renders Anjuta unusable. You can't just ignore the warnings, because if you do, and hit 'refresh' a couple of saves later, you loose all intermediate changes.
I think it's still here but it shouldn't happen if you use the Scintilla plugin.
Hello Sébastien. I'm fairly used to GtkSource-based editors, which are used in several other applications, so I'd prefer not to switch. Would it be too simplistic to change the 'g_file_replace_contents_async' to just 'g_file_replace_contents' in sourceview-io.c (line 370 in version 3.18.2)? I suspect this would wait till the save finishes. As far as I can see, all saves are channeled through this function. Saves (at least local) generally take much less time than clicking on the 'refresh' dialog.
I guess I have to call the callback at the end of the ..._async function to finish the 'save' procedure correctly. I'll try that later. For now, I enabled scintilla. Strange thing: If I just start Anjuta, all is well, but when I change tabs in the editor, one core gets 100% occupied and doesn't stop till I exit Anjuta. *Any* change of tabs causes this (i.e. it is not necessary that a tab scroll occurs). Also, this happens on a clean start of Anjuta - no editing done yet. Is this a known problem?
(In reply to John from comment #6) > I guess I have to call the callback at the end of the ..._async function to > finish the 'save' procedure correctly. I'll try that later. Ok, thanks. > If I just start Anjuta, all is well, but when I change tabs in the editor, > one core gets 100% occupied and doesn't stop till I exit Anjuta. *Any* > change of tabs causes this (i.e. it is not necessary that a tab scroll > occurs). Also, this happens on a clean start of Anjuta - no editing done yet. > Is this a known problem? No, I wasn't aware of that. I have just tried here and indeed I have the same behavior here. Anyway, I need to update Scintilla, there are quite some rendering issue with Gtk 3 but I have not much time to do it.
Hello, Have been annoyed by this too. You should check if the filesystem is mounted with relatime option. Removing it "solved" the problem for me. Hoping this adds some insight ... Michael
Please ignore the last comment. Pressing F7 made it appear again. Sorry for the noise. Michael
Michael, - Compiling the latest GIT version of Anjuta solved this problem for me. (https://github.com/GNOME/anjuta) - Also, as Sebastien noted, if you don't want to compile the latest version, you can enable the Scintilla editor, which doesn't have the problem.
The 100% occupied CPU with Scintilla should be fixed in master. But there isn't anything to fix the original bug so I think it's still here. I imagine that it depends on the time needed to save a file and depending on your system it's common or not.
Hi Sébastien, I _did_ reply about the 100% CPU issue, but it seems that the message disappeared from the forum here. - The 100% CPU problems _is_ solved - The 'File is more recent' problem (with GtkSourceView) also disappeared. The File problem could have disappeared because I update many libraries.
Created attachment 354409 [details] [review] Patch to ignore file changes while saving Here's a possible patch that fixes this annoying problem for me, at least. It makes the sourceview plugin ignore file change events while a save is in progress. If you would want to catch any file changes during the tiny time window between a save being complete and the on_save_finished callback being called, it would take a little more work, not sure if it's worth it, but could be done. (And of course, any file changes before the save completes would be overwritten anyway, unless you give the current etag to g_file_replace_contents_async and stuff.)
Review of attachment 354409 [details] [review]: Thank you for your patch. I cannot reproduce the issue here but your patch looks fine so I have just committed it.
It seems that you have a fix now in the master branch so I'm closing this bug. Do not hesitate to re-open it if something is still not working.
Yes, I suppose this can be a finicky thing to reproduce. I believe I only started getting the problem myself after I switched to ext4.