[Interest] QFileSystemWatcher malfunctioning

[Till Oliver Knoll]

Am 03.02.2012 um 01:04 schrieb "Scott Aron Bloom" <Scott.Bloom at onshorecs.com>:

> I have found with windows at least, its instantaneous.  Essentially it
> sets up a blocking win32 call, that gets release and emits the signal...
> 
> But it does take the event loop of the connected slots thread to be
> running...

... and the later is exactly my point: the underlying implementation can be threaded ("asynchronous") or polling - but in the end it goes through the Qt event queue, and if *your* code is not multi-threaded then there is no point in blocking the signals of QFileWatcher, since the signal would get delivered only *after* your method returns to the Qt event queue anyway (and at that point the mentioned instance of the "signal blocker" would have gone, not blocking anything anymore).

But even if the application code itself was multi-threaded there is no *guarantee* when the OS would actually inform your application. "Instantaneously" might not be fast enough: depending on how fast your method is terminating you might indeed successfully block the signal in 99.9% of all cases - making you wonder why in the other 0.1% your code still seems to think that another process had modified the file, when in fact it was *your* process.

And that off course still does not take into account that on some other platforms the underlying implementation might be polling, and that the polling intervall X might just be slightly larger than the time Y it takes your method to execute (and hence the signal blocker would "live"). And again that would leave you wondering "But my code works on Windows (by chance), but not on Foo OS!"


So if your requirement would be: "For the lifetime of that *method* I don't want to get informed when *I* change that file" then the signal blocker approach would work (taking any possible race conditions out of the equation for now).

For all other scenarios one has to apply application-specific measures, such as some MD5 checksum which has been mentioned several times by now (possibly together with some "file-locking mechanisms" which make the story even more interesting when we talk about files located on network-mapped drives - did I hear "cloud services" just now? ;))

Cheers, Oliver