Many filesystems lack subsecond precision in their stat results, and Node didn't expose this until 0.11 anyway. If the ctime is divisible by 1000, assume that we don't have support for subsecond precision times, and round the staleness option up to the nearest second.
This caused a problem where the use of both wait and stale options together could cause it to think that a lock was stale, when in fact it was not stale.
It's too flaky otherwise, and occasionally the events come in the wrong order. Rather than use a watcher, just keep trying until the time runs out. It's not as elegant, but it also doesn't deadlock on Linux machines.
Retrying only once is incorrect if we're set to wait for a given number of ms, since there might be any arbitrary number of contenders. Also, it was doing 'now - start' as the new wait time, which is incorrect. Instead, calculate the proper end time, and continue retrying until that time is reached, updating the wait time to be 'end - now' at each iteration.
the unlink() triggers watches to try to acquire a lock, but the fd might not be closed yet, leading to a race condition where the new lock gets fs.close'd instead of the old one.