search

bcpierce00 / unison

Unison file synchronizer
GNU General Public License v3.0
4.08k stars 229 forks source link

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

Open pbillen opened 6 years ago

pbillen commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

gdt commented 3 years ago

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

gdt commented 1 year ago

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 commented 1 year ago

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.