Add ability to exclude directories from synchronization based on containing a distinguished file name (e.g. .unison_never_sync)

bcpierce00 / unison

Unison file synchronizer

GNU General Public License v3.0

4.22k stars 237 forks source link

Add ability to exclude directories from synchronization based on containing a distinguished file name (e.g. .unison_never_sync) #635

Open callegar opened 2 years ago

callegar commented 2 years ago

This should probably go together with #593 .

Most software tool that support the general CACHEDIR.TAG also support some analogous but tool-specific way of marking directories to be excluded from operation. In fact, ignore tags placed in directories can nicely complement ignore lists specified on the command line. For instance, the borg backup software supports a tool specific --exclude-if-present option in addition to the --exclude-caches options that deals with the standard CACHEDIR.TAG. A similar mechanism would be quite useful in unison, avoiding the need to update profiles for ephemeral stuff.

bcpierce00 commented 2 years ago

What should happen if a directory exists on both sides but with a .unison_nosync marker only on one side?

   - Benjamin

On Feb 12, 2022, at 4:32 AM, Sergio Callegari @.***> wrote:

This should probably go together with #593 .

Most software tool that support the general CACHEDIR.TAG also support some analogous but tool-specific way of marking directories to be excluded from operation. In fact, ignore tags placed in directories can nicely complement ignore lists specified on the command line. For instance, the borg backup software supports a tool specific --exclude-if-present option in addition to the --exclude-caches options that deals with the standard CACHEDIR.TAG. A similar mechanism would be quite useful in unison, avoiding the need to update profiles for ephemeral stuff.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.

callegar commented 2 years ago

I cannot be sure I am considering the matter on all angles, but I think there are two options:

Because the -exclude-if-present is not a default behavior, but something that is explicitly being asked, I think that it would not be wrong to exclude something if either side says that something is unimportant to sync.
The second possibility is like the previous one, with the addition of a further option (again a la borg) like -keep-exclude-tags. With this option, the tag file (and only the tag file) is synced (possibly with a conflict as needed), so that from the next sync the tag file will be consistent on both sides. Unison could actually invite the user to immediately sync again at the end of a a sync where consistency is reached on a tag file by making it non-existent it on both sides.

gdt commented 2 years ago

A few more comments, assuming someone implements it:

I think this ought to be default, and use some standard filename like .unison_never_sync.
It could have an option to disable it, but I'm not sure that is really necessary.
The semantics should be as if each dir with the magic file has been added to the exclude list, so no additional thought is needed.
A PR should add tests and adjust the docs, for user-visible changes.
wontfix isn't meant to be unkind, but more of a clue that I am not going to spend time on it (it solves a problem I don't have, as I organize my replicas by kind of data in terms of how many backups I want and where the data is allowed, and I sync them in their entirety). It should not be viewed as discouraging others to work on it if they want.

gdt commented 2 years ago

I guess the exclude list is for the pair of roots, and this would be on one root only. So I amend my comment to say that Unison should act as if the path is on the exclude list if either side has the magic file.

bcpierce00 commented 2 years ago

I would phrase it a bit differently: If the magic file exists on one side and the other side is nonempty, Unison should give an error instead of doing nothing.

With that proviso, I have no objection to this change. But I think it's nontrivial to implement correctly.

On Sun, Feb 27, 2022 at 11:36 AM Greg Troxel @.***> wrote:

I guess the exclude list is for the pair of roots, and this would be on one root only. So I amend my comment to say that Unison should act as if the path is on the exclude list if either side has the magic file.

— Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https://github.com/bcpierce00/unison/issues/635*issuecomment-1053609294__;Iw!!IBzWLUs!HAcW4YerPEBfpxMxmp9fgv_Udu-bh4aVMwXbfiyLB3vw6vabKYHPCOLiGSiNUuPk08Q$, or unsubscribe https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABVQQCZ6CFSHXBJGZV26Z4LU5JHJ3ANCNFSM5OGPY7ZQ__;!!IBzWLUs!HAcW4YerPEBfpxMxmp9fgv_Udu-bh4aVMwXbfiyLB3vw6vabKYHPCOLiGSiNjjXsxHk$ . Triage notifications on the go with GitHub Mobile for iOS https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!IBzWLUs!HAcW4YerPEBfpxMxmp9fgv_Udu-bh4aVMwXbfiyLB3vw6vabKYHPCOLiGSiN6OIewdw$ or Android https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!IBzWLUs!HAcW4YerPEBfpxMxmp9fgv_Udu-bh4aVMwXbfiyLB3vw6vabKYHPCOLiGSiNoImBsfc$.

You are receiving this because you commented.Message ID: @.***>