[PATCH] Hotloading fails if FAMCreated and FAMDeleted events occur in same polling

[historic_bruno]

While troubleshooting hotloading/FAM on Ubuntu 12.04, I noticed that editing a GUI page in gedit was not triggering correct hotloading behavior - for some reason it was ignoring the FAM events. Using gdb I found the following sequence of events in a single call to dir_watch_Poll():

Created /home/ben/0ad/binaries/data/mods/public/gui/pregame/.goutputstream-HV66KW

Changed /home/ben/0ad/binaries/data/mods/public/gui/pregame/.goutputstream-HV66KW

Created /home/ben/0ad/binaries/data/mods/public/gui/pregame/mainmenu.xml~

Deleted /home/ben/0ad/binaries/data/mods/public/gui/pregame/.goutputstream-HV66KW

Created /home/ben/0ad/binaries/data/mods/public/gui/pregame/mainmenu.xml

I believe the bug occurs when the temporary file .goutputstream-HV66KW is created and deleted between calls to dir_watch_Poll(). By the time the notification is processed, the file has already been deleted. When ReloadChangedFiles()​ tries to remove the file from VFS, it silently fails and all further notifications from that polling are lost. The change to mainmenu.xml occurs last and is never processed.

If instead I directly overwrite mainmenu.xml with another file, hotloading works as expected.

I will also test with #1316 but I suspect the bug will still exist since it's a higher level issue in ReloadChangedFiles().

[historic_bruno]

Confirmed that the bug still occurs with the inotify patch from #1316 (though the events are slightly different).

[ben]

In 12726:

Replaces FAM file monitoring with inotify on Linux, based on patch by noKid. Fixes #1316, refs #1687.
Removes FAM dependency.

[leper]

Shouldn't merging (or rather dropping) all messages for one file suffice?

I decided to give it a try, but I couldn't even get any feedback (not even a print statement in dir_watch_add gave something back...).

[leper]

As I've been touching that code (or rather code related to it) recently I wondered why we are using RETURN_STATUS_IF_ERR() in there instead of just logging errors and calling continue which would remove this issue. Also I'd be for relaxing the check when removing to allow both INFO::OK and ERR::VFS_FILE_NOT_FOUND to make addition of new files use the same code path.

(Note to adding files: The current code is a bit broken in regard to this currently as adding a file will be ignored, but changing it will trigger the file to show up, so callers already have to check for additions of new files (if they don't want to support it))

[leper]

Rough prototype

[leper]

Above patch doesn't apply cleanly anymore. I do have an updated but untested version around somewhere, but for now this isn't really up for review.