Re: Feature request: confirm data loss when renaming folder with ignored files

On Fri, 14 Jul 2023 at 00:47, Greg Troxel <[email protected]> wrote:
>
> My take is:
>
>   do not do any recursive deletes, ever
>
>   only delete a directory if it is empty.  Otherwise, error out and make
>   the user fix it
[plus from the other mail]
> So, if we add the "unison may not delete files other than if they are
> explicitly deleted as part of sync" rule, and people have to manually
> cope if they run into it, does anything bad happen?

I think I could be convinced to get onboard with this but it may not
be a one-size-fits-all. When you say "error out", do you mean that
nothing should be deleted or only delete files/subdirs that were
explicitly synced and leave the rest behind?

I can think of three different scenarios (plus combinations of these).
Each could have different processing.

First, deleting (or renaming) a directory which has ignored children.
Should this deletion not be propagated at all? Should it result in
deleting only the synced files/subdirs? For reference, currently
everything will be deleted. This seems ok to me, possibly with a
warning.

Second, deleting (or renaming) a directory which has children covered
by "noupdatepartial" or "nodeletionpartial" preferences. Same
questions as above. For reference, currently everything will be
deleted. This does not seem ok to me, warning or not.

Third, deleting (or renaming) a directory which does not have any
ignored or "no*partial" children, but which does have updated or new
to-be-synced children. Currently, a conflict is reported and if
overridden to propagate the deletion then everything will be deleted.
This seems ok and desirable to me.

The current processing in the second scenario strikes me as unexpected
and I think it could even be classified as a bug.

For processing the first scenario (which this thread is primarily
about), I can see both ways being useful (as also evidenced by
messages in this thread), maybe going as far as controlling it via a
user preference (which we'd rather avoid adding).

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].