The stale option is checked using file creation time, which is sometimes incorrect in windows: If you delete a file and recreate the file with the same name within 15 seconds (default), the new file will have the same creation file as the old deleted one. this is said to be "working as intended", and called "Windows NT File System Tunneling", it affect all recent windows system from Windows XP to latest Windows 8 64bit.
Expected result:
the last lockSync call will throw an error with EEXIST and the lock file stat is like:
atime: Fri Aug 23 2013 10:08:36 GMT-0400 (EDT)
mtime: Fri Aug 23 2013 10:08:36 GMT-0400 (EDT)
ctime: Fri Aug 23 2013 10:08:36 GMT-0400 (EDT)
atime: Fri Aug 23 2013 10:08:47 GMT-0400 (EDT)
mtime: Fri Aug 23 2013 10:08:47 GMT-0400 (EDT)
ctime: Fri Aug 23 2013 10:08:47 GMT-0400 (EDT)
Actual result:
show dup lock done and ends without exception, the lock file stat is like:
atime: Fri Aug 23 2013 10:09:45 GMT-0400 (EDT)
mtime: Fri Aug 23 2013 10:09:45 GMT-0400 (EDT)
ctime: Fri Aug 23 2013 10:09:45 GMT-0400 (EDT)
atime: Fri Aug 23 2013 10:09:56 GMT-0400 (EDT)
mtime: Fri Aug 23 2013 10:09:56 GMT-0400 (EDT)
ctime: Fri Aug 23 2013 10:09:45 GMT-0400 (EDT)
The work around i am using is to use the file modification time instead of creation time on windows. on other system, the mtime should also work but i only tested on linux.
The stale option is checked using file creation time, which is sometimes incorrect in windows: If you delete a file and recreate the file with the same name within 15 seconds (default), the new file will have the same creation file as the old deleted one. this is said to be "working as intended", and called "Windows NT File System Tunneling", it affect all recent windows system from Windows XP to latest Windows 8 64bit.
See more details about this at: http://support.microsoft.com/kb/172190/en-US http://serverfault.com/questions/92757/incorrect-file-creation-date-in-windows-xp-vista
This will cause problems for lockfile when you lock the same file repeatly and are using the stale option.
sample code to always reproduce the problem:
Expected result: the last lockSync call will throw an error with EEXIST and the lock file stat is like: atime: Fri Aug 23 2013 10:08:36 GMT-0400 (EDT) mtime: Fri Aug 23 2013 10:08:36 GMT-0400 (EDT) ctime: Fri Aug 23 2013 10:08:36 GMT-0400 (EDT)
atime: Fri Aug 23 2013 10:08:47 GMT-0400 (EDT) mtime: Fri Aug 23 2013 10:08:47 GMT-0400 (EDT) ctime: Fri Aug 23 2013 10:08:47 GMT-0400 (EDT)
Actual result: show dup lock done and ends without exception, the lock file stat is like: atime: Fri Aug 23 2013 10:09:45 GMT-0400 (EDT) mtime: Fri Aug 23 2013 10:09:45 GMT-0400 (EDT) ctime: Fri Aug 23 2013 10:09:45 GMT-0400 (EDT)
atime: Fri Aug 23 2013 10:09:56 GMT-0400 (EDT) mtime: Fri Aug 23 2013 10:09:56 GMT-0400 (EDT) ctime: Fri Aug 23 2013 10:09:45 GMT-0400 (EDT)
The work around i am using is to use the file modification time instead of creation time on windows. on other system, the mtime should also work but i only tested on linux.