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

Tõivo Leedjärv <[email protected]> writes:

> 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 mean that files that are ignored should not be removed.

> 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.

I think the basic issue is that deleting a file that isn't under the
control of unison is just not ok.  The present reports of trouble are
essentially this.  Deleting the files that are synced is fine.

> 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.

Certainly the docs are clear that nodeletionpartial should prevent
deletion.  It should not prevent a rename, but a rename that drops files
should be prevented.  I don't see that noupdatepartial is relevant to
deletions.

> 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.

yes

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

agreed

> 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).

I think we should just make it be an error, preventing the deletion of
the directory if synced deletions don't empty it, at let people remove
things themselves if they want to proceed.   That's safe, at the expense
of being annoying.  But my view is that selective ignoring of files
leads to trouble in the first place....

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