Low Resolution of Modification Timestamp is problematic

[roland-ruedenauer]

The mtime metadata property uses a timestamp resolution with a resolution of 1 second only.
When quickly creating revisions of the same item (e.g. during testing), they may end up having the same mtime value.
This makes it impossible to tell exactly, which item has been created latest, as mtime sort order is used by moin.

Some unit tests use sleep(1.1) to avoid running into this problem.

To do: find a good solution to avoid the ordering problem (increase mtime resolution, use a different field for ordering revisions, ...)

[ThomasWaldmann]

Don't we have that "parent" metadata? It's a bit more effort, but that could be use to determine the order also.

Some filesystems have a rather bad timestamp granularity, famously FAT and HFS+, but of course we could switch to nanosecond timestamps even if that isn't the effective granularity then.

[ThomasWaldmann]

For testing purposes, I recently introduced a granularity_sleep helper in borgbackup that, depending on the platform, sleeps long enough to avoid issues. That makes it fast on Linux and slow only on Mac/Windows.

[roland-ruedenauer]

granularity_sleep

This is a workaround isolating the problem. But it is not a solution. Delaying multiple unit tests in the range of seconds as simply something you should not do.

Moin also has rev_number that could be used to establish an ordering. But my point was mainly to document the problem for now.

[ThomasWaldmann]

Note: rev numbers are problematic if there are parallel updates.

[roland-ruedenauer]

Yes, but parallel updates currently already are a problem because the do not ensure consistency in any way. That's at least how I understood the existing code.

[ThomasWaldmann]

Yes, it's difficult, no matter how one addresses that (locking, merging, realtime collab editor).