Race condition on filesystems with low-precision mtime

[WhyNotHugo]

Following up on #575, I realized that there's a possible (although very unlikely) race condition on file-systems where precision is only in seconds. During the same second:

1. A file is written.
2. The file is cached [by khal].
3. A file is re-written.

The cache will now keep the first version of the file, and will believe it's up-to-date.

As a possible solution, I'd like to propose:

• Measure the mtime precision for each calendar at startup (similar to this).
• If the FS is lo-precision set some special internal flag to slow_fs to True.
• When reading files from disk if mtime == int(datetime.now().timestamp()) (ie: the file was written during this second), set the mtime in the cache to one second in the past (edit just mtime - 1 will do).

This will result in the cache for a file written during the second is was read always expiring. The frequency of this happening should be very very low, but we'll avoid the race condition outlined above.

To summarize, this would add very very few occasional re-read, to avoid keeping stale data in the cache.

Rather than an actual PR, I wanted to discuss this first, because:

1. Will we care enough about this?
2. Maybe somebody has a better idea?

[untitaker]

If you really care about this you could also take a combination of inode number, file size and mtime. All of this is returned from stat at once so you don't have any extra syscalls. This doesn't make a bad cache impossible like your suggestion, but IMO decreases the probability sufficiently.

[WhyNotHugo]

inode does not change across saves. I do agree that file size reduces this considerable, but I'm sure if it's enough.

[untitaker]

inode does change if you use atomic file writes.

[WhyNotHugo]

Yes, you're right.