Add ability to always use `copyprog` for updates to work around lack of permissions (rsync --fake-super)

[pbillen]

Hi all,

I am using Unison to synchronize files between several clients. For this, it is important that ownership is preserved. Since I am syncing to a cloud server with non-root access (meaning chat chmod is not possible), I believe my only resort to preserve ownership is relying on rsync via the copyprog configuration parameter and the usage of --rsync-path=="rsync --fake-super". (Please correct me if you have another idea.) However, I noticed that copyprog is only used for new files, not for updates. This is also stated in the documentation and confirmed in https://github.com/bcpierce00/unison/issues/65#issuecomment-279940469.

More context can be found at https://unix.stackexchange.com/questions/468227/unison-always-use-copyprog-for-updates.

In summary, I would like to propose a feature/enhancement to be able to configure that all file transfers (that is, new and updated files) will be handled by the copyprog application. This way, I believe that ownership will never be lost, as explained in the SO question.

What do you think?

FYI, I believe that the proposal of the introduction of copyprogalways = true as explained in https://github.com/bcpierce00/unison/issues/65#issuecomment-279963123 should solve this request.

Thanks!

[bcpierce00]

Sounds reasonable; if someone wants to implement it, I will be happy to consider a PR.

Since this would add a new option, I'd want to combine it with #5, so that we would not have to increment the version number.

[pbillen]

Great! I have unfortunately zero experience with OCaml, but you can count me in to beta test the PR.

[gdt]

The notion of synchronizing owner and not being able to set owner raises non-obvious correctness questions.

[gdt]

This seems to be about using rsync to construct a stacked filesystem that represents ownership but can be stored in an underlying filesystem that does not support it. It may be that it is cleaner to implement a stacked filesystem and sync to it.

Note the call on unison-users earlier today for reasons not to entirely remove external rsync support.

[tleedjarv]

It is not unthinkable to implement support for rsync's fake-super xattr directly in Unison (assuming there is a stable spec for that xattr). (Edit: The xattr data format is super-simple and appears to be unchanged since it was introduced in 2007. Of course, Unison could just use its own xattr to achieve the same result.) Something similar, or basically the same thing, is already done for MacOS (the original one) resource forks and FinderInfo.