axkibe/lsyncd — Issue #61: Inotify IN_CLOSE_WRITE results in many useless calls to rsync
Author: axkibe
Created: 2011-11-16 15:06:11+00:00
State: open

Originally filed by randy.re...@gmail.com on 2011-05-23T21:05:39

What steps will reproduce the problem?
1. Write application that opens file with read and write privileges allowed
2. Run application, the app should open the file and NOT write to it, then close the file.
3. An IN_CLOSE_WRITE inotify event will be raised, however the modifications will have been made and modified timestamp will not have been changed on file either.

What is the expected output? What do you see instead?
No synchronization should occur as nothing has been modified. Instead I see lsyncd calling rsync due to 'new/modified files/dirs'.

What version of the product are you using? On what operating system?
Using version 2.0.4. Centos 5.6 OS, 2.6.18-238.9.1.el5 x86_64

Please provide any additional information below.

Lsyncd has been working marvelous for us. The downfall after upgrading to version 2.0.4 from the 1.3.x branch is the fact that Lsync now makes use of IN_CLOSE_WRITE events rather than IN_MODIFY. I see the advantages to using this method, however in my scenario it is causing a lot of useless rsync calls.

In particular when lsync is monitorying SVN repositories it is receiving a IN_CLOSE_WRITE notification on svn/db/rep-cache.db every 1 minute. I'm not sure what process is accessing this file, nonetheless it appears to be opening the file with write privileges but does not write to the file every minute that it opens it.

Example c++ app to test with:
#include
#include
using namespace std;

int main()
{
// open file ''test.txt'' for reading and writing
filebuf buffer;
ostream output(&buffer);
istream input(&buffer);
buffer.open ("test.txt", ios::in | ios::out );
// Do not actually write anything to the file, just close it.
buffer.close();
}