Am 11.05.2017 um 00:40 schrieb Guillaume MM <g...@lyx.org>: > > Le 10/05/2017 à 22:57, Stephan Witt a écrit : >> Am 09.05.2017 um 21:19 schrieb john kennan <jken...@ssc.wisc.edu>: >>> >>> Start a new file >>> type something >>> save >>> type some more >>> save >>> >>> I get "the file ... changed on disk." with two buttons: "Reload" and >>> "Ignore" >>> >>> hitting Ignore leaves the file unsaved >>> hitting Reload works -- I get a warning: >>> >>> Any changes will be lost. Are you sure you want to load the version on disk >>> of the document .../Papers/LyX/test1.lyx? >>> >>> with buttons for Revert and Cancel >>> Hitting Revert saves the file, as desired, and the changes are not lost. > > Dear John, thanks for the report.
+1 - thank you for testing! > This looks like LyX incorrectly > recording the modification it has made itself as an external > modification. This means that in fact the file is already correctly > saved when the message shows up, and the two buttons do nothing except > annoy. I am looking into it. > > Does it happen only on the second save? Does it happen on the third save > if you carry on? Does it not happen on the first save? If not, is it > because the first save is a "Save As"? > >> >> Confirmed. > > Dear Stephan, thanks for the test. This looks specific to OSX. I would > ask the same questions as above. On the first save LyX asks for a file name because it’s a new file. This in fact is a Save-As operation. The save succeeds normal. After that every change+save is accompanied by the message popup. NB: I’m accepting the file name proposal - so it’s the same file name before and after the save-as. >> Guillaume, it’s the FileMonitor which is detecting the file save as external >> modification. >> How can I provide further info to correct this annoying behavior? >> My attempt to diagnose the culprit failed - the code is too weird for me :( >> >> I tried to stop in Buffer::Impl::refreshFileMonitor() at the first line. >> The debugger didn’t stop - but it stopped in >> Buffer::Impl::fileExternallyModified() >> and the call stack claims it comes from the last line in >> refreshFileMonitor() ??? > > As QFileSystemWatcher is intrinsically asynchronous, gdb does not really > help with debugging here. What you see on the trace is > QFileSystemWatcher calling the function that was passed to connect at > the end of refreshFileMonitor (via a qt signal that is converted into a > boost signal). That makes sense. BTW, what’s the semantic of a void C++ function when it returns a value (2nd line after the if())? I’m surprised it’s allowed. Now I have to go… I’ll answer the other questions later. Stephan > What should happen is inside Buffer::save there is a FileMonitorBlocker > that should block the signal. Now, since QFileSystemWatcher is > asynchronous, the signal is not received before the next iteration of > the even loop. At this point the FileMonitorBlocker has been destroyed a > long time ago. This is why FileMonitorBlocker unblocks the signal in an > asynchronous way too, using a QTimer. On Linux, a delay of 0 (meaning > wait until the next event loop) is enough to actually block the signal. > > The delay is defined in Buffer::Impl::blockFileMonitor (Buffer.cpp:388) > currently at 10ms. Can you try to increase this value and see if that > helps? It will likely help, but this is not a nice solution. > > Ideally I would like to have everything work with a delay of 0ms, to be > sure that everyone experiences the same. Can you help me and see if it > is possible to flush the file operations in FileName::copyTo and > FileName::moveTo and if it makes a difference ? There is QFile::flush > but I do not really see how to use it in this context and I cannot test > the situation. > >> >> Frankly said: I’m lost now. > > For this bug and the other similar bug on the bugtracker [down currently > again] I thought about detecting false positives by comparing the file > hashes before setting the flag. > > Before this drastic measure I would like to see if I can understand why > the signal comes too late for the blocker, and if it's just missing > something simple. > > > Guillaume
