Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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

Open
pbillen opened this issue Sep 11, 2018 · 6 comments
Labels
discuss way forward is unclear; needs discussion of approach to take and why effort-high issue is likely to require >20h of effort, perhaps much more feedback Information has been requested; may be closed in 30 days if not provided. impact-low low importance wontfix maintainers choose not to work on this, but PR would still be considered

Comments

@pbillen
Copy link

pbillen commented Sep 11, 2018

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 #65 (comment).

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 #65 (comment) should solve this request.

Thanks!

@bcpierce00
Copy link
Owner

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
Copy link
Author

pbillen commented Sep 11, 2018

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

@bcpierce00 bcpierce00 added help wanted effort-low issue is likely resolvable with <= 5h of effort labels Oct 12, 2018
@gdt gdt removed the help wanted label Sep 14, 2020
@gdt gdt added discuss way forward is unclear; needs discussion of approach to take and why effort-medium issue is likely resolvable with <= 20h of effort and removed effort-low issue is likely resolvable with <= 5h of effort labels Oct 23, 2020
@gdt
Copy link
Collaborator

gdt commented Oct 23, 2020

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

@gdt gdt changed the title Feature/enhancement: always use copyprog for updates Add ability to always use copyprog for updates to work around lack of permissions (rsync --fake-super) Feb 27, 2022
@gdt
Copy link
Collaborator

gdt commented Mar 19, 2023

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
Copy link
Contributor

tleedjarv commented Mar 19, 2023

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.

@gdt gdt added wontfix maintainers choose not to work on this, but PR would still be considered impact-low low importance labels May 7, 2024
@gdt
Copy link
Collaborator

gdt commented Oct 18, 2024

@pbillen Note that we are about to remove external rsync support. It's been 6 years since the issue was opened, so it seems unlikely that anyone will ever work on this. I'll leave it open today, but it's going to get close when #871 is resolved.

@gdt gdt added effort-high issue is likely to require >20h of effort, perhaps much more feedback Information has been requested; may be closed in 30 days if not provided. and removed effort-medium issue is likely resolvable with <= 20h of effort labels Oct 18, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
discuss way forward is unclear; needs discussion of approach to take and why effort-high issue is likely to require >20h of effort, perhaps much more feedback Information has been requested; may be closed in 30 days if not provided. impact-low low importance wontfix maintainers choose not to work on this, but PR would still be considered
Projects
None yet
Development

No branches or pull requests

4 participants