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

On Wed, 12 Jul 2023 at 11:59, Greg Troxel <[email protected]> wrote:
>
> "Jorge P. de Morais Neto" <[email protected]> writes:
>
> First, thank you for bringing this on the mailing list.
>
> > Unison manual does warn:
> >
> >> Be careful about renaming directories containing ignored
> >> files.  Because Unison understands the rename as a delete plus a
> >> create, any ignored files in the directory will be lost (since they
> >> are invisible to Unison and therefore they do not get recreated in the
> >> new version of the directory).
> >
> > I have just triggered that scenario and lost my Elfeed¹ database.  I had
> > only an old backup.  Yes, I should have been more careful, but human
> > users have imperfect attention and Unison behavior is error-prone.  Why
> > does Unison not warn the user and confirm when renaming directories with
> > ignored files?
>
> I think the answer is probably more or less "because ignored files are
> not important, by the definition of what should be ignored."

I'm a bit torn about this statement. On one hand, "ignore" means
"pretend it's not there" (for purpose of the sync) and in that sense
Unison has not directly done anything wrong. One the other hand,
"ignore" does not mean "not important" and it should not mean "go
ahead and delete these for me (or alter in some way)". Some kind of
warning in the UI might make sense.

It's not exactly new knowledge that propagating renames the way it's
done now can under specific conditions lead to temporary data loss, in
some cases even to permanent data loss, and I've also submitted bug
fixes in that spirit.

On a related note, I have a PR open for syncing renames as renames
instead of the current copy+delete. I've mentioned in the PR
discussion that it is not just for user's convenience, it is actually
safer to do it this way. Yet there are other issues to be solved
before that PR can be considered for merging so it won't be any time
soon. Even if merged, it would not always work, as it has some rather
strict prerequisites.


A slight change of topic. Thinking about the strict view of "never
alter ignored files/dirs in any way", I looked at preferences like
"nodeletionpartial" and "noupdatepartial". A "cautious" option, as
suggested by Jorge, could automatically produce "nodeletionpartial" or
"noupdatepartial" preferences based on "ignore" preferences. However,
I just discovered that the "nodeletionpartial" preference does not
work as expected because it affects the update reconciliation step,
but not the propagation step. As such, a -nodeletionpartial 'Path
sub/subsub -> root1' will happily allow deleting the entire path
'sub', including 'sub/subsub' in it.

I suppose the entire topic of "don't touch what you're not supposed to
touch" requires some rethinking when it comes to deleting (parent)
directories (this includes renaming). I don't intend to do it myself
but it would be interesting to hear ideas from people interested in
this topic.

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