file was incorrectly transferred (fingerprint mismatch in resource fork)

[dnjackson]

Unison fails on a directory containing a few pdf files. I've never seen this failure before, and everything else is syncing fine. I can't see anything unusual about the files or the directory they're in (eg wrt permissions). Any ideas?

Unison 2.53.3 (ocaml 4.14.1) started propagating changes at 20:55:56.69 on 09 Jan 2024 [BGN] Copying .../foo.pdf from /Users/... to //csail//afs/... Failed [../foo.pdf]: The file .unison.foo.pdf.6b93e92233611bf8bf3e72675409d5c6.unison.tmp was incorrectly transferred (fingerprint mismatch in resource fork) -- temp file saved as /afs/.../.unison.foo.pdf-bad.6b93e92233611bf8bf3e72675409d5c6.unison.tmp Unison 2.53.3 (ocaml 4.14.1) finished propagating changes at 20:55:56.86 on 09 Jan 2024, 0.169 s

Saving synchronizer state Synchronization incomplete at 20:55:58 (0 items transferred, 0 skipped, 1 failed) failed: ../foo.pdf

[gdt]

This seems like a request for help debugging which should be directed to the unison-users mailinglist (see wiki) rather than the issue tracker, which is for bug reports only (and well-articulated feature requests).

My read of the output is:

• you are using a mac
• you have a file with a resource fork, and I have no idea if that is or is not unusual these days. The unison manual doesn't mention resource forks, egrep tells me weakly, but src/osx.ml says there is, so a doc PR is welcome.
• you are syncing from a local file to AFS, which as you know is very unusual in unison land even if is usual in your environment :-) I have no idea if AFS supports resource forks and no idea if trying to write one on your system results in EOPNOTSUPP, silent discard, or something else.
• unison transferred the file to a tmp name, and the post-transfer checksum to see if it was done correctly failed. It would rename it if it passed the check. See src/copyml.
• therefore this points (weakly) to a filesystem issue
• it claims the temp file was left, so you can check it vs the original

If you can come up with ktrace/dtrace/etc. that shows that data across the user/kernel interface from the unison process is wrong, that of course counts as a unison bug. rsync may be helpful in debugging.

[dnjackson]

Many thanks, and apologies for posting in the wrong place. I wonder if it's possible to put a link to your "Mandatory Reading Before Using the Issue Tracker" on the issue tracker page!

I'll look into these things.

Thank you also to you and the team for continuing to work on Unison---it's fantastic.

[tleedjarv]

This does seem like a filesystem issue but hard to say without more debug info.

On macOS the rsrc preference is enabled automatically. If you know that you don't need to sync resource forks and FinderInfo then you can just set rsrc to false and errors like this go away. (Unfortunately, syncing resource forks and FinderInfo is controlled by a single preference. I'm not a Mac user, so I don't know if it would make sense to separate those or not.)

[gdt]

I'm going to sort this into "filesystem bug, not a unison bug" for now, and will be happy to reopen if there's contrary evidence.