Incorrect mtime displayed for unchanged files/dirs in some cases

[tleedjarv]

First, this is not a syncing issue.

Consider the following scenario:

$ echo test1 > testa
... wait for a while to make the difference in mtimes more obvious ...
$ echo test1 > testb
$ unison -times=false testa testb
Nothing to do: replicas have been changed only in identical ways since last sync.

$ stat testa testb
  File: testa
Modify: 2025-01-18 10:43:28
  File: testb
Modify: 2025-01-18 10:43:44
$ echo test2 > testa
$ stat testa testb
  File: testa
Modify: 2025-01-18 10:44:35
  File: testb
Modify: 2025-01-18 10:43:44

$ unison -times=false testa testb
testa          testb              
changed  ---->              [f] x
testa        : changed file       modified on 2025-01-18 at 10:44:35  size 6         rw-r--r--
testb        : unchanged file     modified on 2025-01-18 at 10:43:28  size 6         rw-r--r--

Notice how for the unchanged file testb an incorrect modification time is displayed. Looking closer, the time displayed is the previous mtime of the modified file testa.

This happens for files when the times preference is off. This happens for directories regardless of the times preference value because dir mtimes are not synced (effectively behaving as if times=false).

The cause

When updates are scanned, all unchanged files and dirs are simply reported as unchanged, without any additional information. Changed files and dirs (regardless of the nature of the change) are reported with the details of the change together with the previously synced details as stored in the archive.

During reconciliation, the data of previous details from the changed side are also used for the unchanged file/dir to fill in the previous (= current) details of the unchanged file/dir. This is ok because the archives contain synced information so the details are expected to be the same in each archive.

However, there is some data in the archives that is not equal between the archives:

• mtimes when times=false
• mtimes for directories regardless of times preference

As far as I can tell, only mtimes are affected currently. In general, any details that are recorded as props in the archive and displayed to the user but not actually synced on disk would be affected. (Note that there is other data in the archives that is not equal between them, yet not displayed to the user, such as inode numbers or status change times; this ticket is not about such data.)

Impact and resolution

Importantly, this is not a syncing issue! This is a display issue only, possibly confusing the user. The main impact is with times=false (which should be considered an exception rather than normal), directory mtimes being less relevant (and possibly should not be displayed at all?).

I am opening this ticket for the record only. As something to consider if props is in future extended with similar non-synced-but-displayed details or when deciding to display inherently non-equal details (such as the aforementioned inode numbers).

Actually fixing this issue is possible, of course, but would in practice mean sending over the entire archive from the remote host to the client and keeping it in memory (which could be hundreds of MB for huge replicas, as discussed recently). This is not feasible at the moment.