[texworks] external read-access causes TeXWorks to revert open file to old version

[Stefan Löffler]

Hi,

Am 2010-11-01 18:24, schrieb Stefan Müller:
>
> On 28.10.2010 20:13, Stefan Löffler wrote:
>> I think I mentioned this before, but your problem may be related to a
>> race condition. Just as Tw detects a change (to either the directory or
>> the file), further change-detection is disabled for the duration of the
>> processing. So if mercurial changes the file/directory, Tw may register
>> this and start its processing (doing lots of checks, remembering where
>> you were in the file, etc.). Then, it loads the file. Then it tries to
>> restore the previous state. And only then it re-enables the file system
>> checker. So if mercurial changes the file twice for some reason (or
>> changes the directory first possibly with the last committed version of
>> the file and then replaces the file), Tw may pick up the wrong version.
>> To verify this, could you put the following line just after the `[1094]
>> qDebug()<<  "Changed:"<<  curFile;` line:
>> qDebug()<<  fileModified;
>> This should print the file modification time during each reload. Could
>> you then compare these to the timestamp output by `ls -l --full-time` on
>> the command line in both a "normal" and a "positive" run? This could
>> give us an indication whether Tw picks up a different version of the
>> file.
>>
> I tried that additional debug line you suggested. During a "normal"
> run I don't get the "Changed" line so I don't get the timestamp either
> (other suggestions?). During a "positive" run, the debug message shows
> me the timestamp from that moment when the commit was done. But `ls -l
> --full-time` shows me exactly the time when I saved the tex file (e.g.
> 30 seconds earlier).

Yes, this seems to confirm my theory.
First of all, you should get the "Changed" line only if the file is
actually being reloaded. Which it shouldn't be, if the file wasn't
changed externally - that's the whole point ;).
Now, the fact that Tw prints a later time-stamp during a positive run
than a subsequent invocation of `ls` suggests that the file is indeed
written twice. First the file is changed during the commit, which Tw
picks up. Then, the original file (with the earlier timestamp) is
restored, but Tw doesn't pick that up (probably because it is still
processing the first change). As such, this naturally only happens
occasionally (if mercurial takes a certain time to process the commit).

Unfortunately, I don't see a quick fix for this. One thing would be to
never reload a file unasked. This would be a bit of an inconvenience for
"normal" users, though. Another possibility would be to process the
updates in a separate thread, thereby keeping track of all changes. Or
to check the file state again after the loading (and rerun the reload
method in case the file has changed again in the meantime). This last
option strikes me as the safest one.

Have you been in touch with the mercurial people? Did they say anything
about the two stages of the commit?

HTH
Stefan