The log tracking capability on Windows has a serous race condition where certain file attributes cannot be read due to a silent failure in the sigar_fileinfo.c@fileattrs_get method. In certain cases a call to create file will fail when the GENERIC_READ and FILE_SHARED_READ flags are being used. This is documented by MDSN (see: http://msdn.microsoft.com/en-us/library/aa363874%28VS.85%29.aspx). If SIGAR tries to read a file after another process, presumably the owner of the log file, with these creation flags the SIGAR API silently fails and assigns the file attributes to 0. This is becomes apparent if you turn up the agent's debug level for SIGAR. In our particular scenario the agent is started after the log owner process has been writing to the file for period of time before we start the agent process. After the agent starts we see the following in the agent.log (NOTE: Nlink, Device, Inode are all 0).
After the agent has been running for an extended period of time the following message can also been seen.
The following errors are spurious but occur many times depending on the ordering of process read/writes documented in the MSDN page. Unfortunately, when an inode change is detected the entire log file is parsed from the beginning of the file which in our case has caused several false alerts to get triggered in our HQ server. Since the Win32 implementation of fileattrs_get is only concerned with reading certain device values a workaround exists simply by changing the access credentials. The CreateFile MSDN page (http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx) explicitly states the following about the dwDesiredAccess flag.
"If this parameter is zero, the application can query certain metadata such as file, directory, or device attributes without accessing that file or device, even if GENERIC_READ access would have been denied."
In order to fix the race condition we just need to modify the following code segment in sigar_fileinfo.c@fileattrs_get method from:
to:
I have fixed this locally in a patch build for our environment and verified that it works as expected. I have also attached a diff against the github HEAD with the appropriate changes to this post. FWIW, the changes I describe are well documented and used by several other implementations. See the following link as examples.
see:
http://gnuwin32.sourceforge.net/compile.html @ Inode numbers
http://git.savannah.gnu.org/cgit/emacs.git/tree/src/w32.c#n2730
http://code.google.com/p/libarchive/source/browse/trunk/libarchive/archive_windows.c#652
2010-01-27 15:48:14,403 DEBUG [Thread-2] [FileTail] add: D:\integration\servicemix\data\log\servicemix.log={Type=1, Nlink=0, Mtime=1264611812948, Ctime=1228839338714, Gid=0, Permissions=1911, Size=13070913, Device=0, Atime=1264624430389, Inode=0, Uid=0}
After the agent has been running for an extended period of time the following message can also been seen.
2010-01-27 11:04:11,603 DEBUG [FileWatcherThread] [FileTail] D:\integration\servicemix\data\log\servicemix.log: file inode changed
The following errors are spurious but occur many times depending on the ordering of process read/writes documented in the MSDN page. Unfortunately, when an inode change is detected the entire log file is parsed from the beginning of the file which in our case has caused several false alerts to get triggered in our HQ server. Since the Win32 implementation of fileattrs_get is only concerned with reading certain device values a workaround exists simply by changing the access credentials. The CreateFile MSDN page (http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx) explicitly states the following about the dwDesiredAccess flag.
"If this parameter is zero, the application can query certain metadata such as file, directory, or device attributes without accessing that file or device, even if GENERIC_READ access would have been denied."
In order to fix the race condition we just need to modify the following code segment in sigar_fileinfo.c@fileattrs_get method from:
handle = CreateFile(file,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
flags,
NULL);
to:
handle = CreateFile(file,
0,
0,
NULL,
OPEN_EXISTING,
flags,
NULL);
I have fixed this locally in a patch build for our environment and verified that it works as expected. I have also attached a diff against the github HEAD with the appropriate changes to this post. FWIW, the changes I describe are well documented and used by several other implementations. See the following link as examples.
see:
http://gnuwin32.sourceforge.net/compile.html @ Inode numbers
http://git.savannah.gnu.org/cgit/emacs.git/tree/src/w32.c#n2730
http://code.google.com/p/libarchive/source/browse/trunk/libarchive/archive_windows.c#652