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

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

Personally, I see ignoring files (other than editor backups, built
objects) as something best avoided.  I have a number of directories and
sync them; files I don't want synced are organized into other
directories.  I do not have *any* ignore rules.  Which is a sideways way
of saying that I won't work on this because I don't have this problem.

Why are you declining to sync something that is important, while wanting
to sync the containing directory?  I really am curious, because I find
that people are wanting to use ignore all the time, in ways that don't
make sense to me.

You didn't really say what you did.  I am guessing you had on host A
directory foo with some stuff and bar.elfeed.  Synced with unison to
host B, which is missing bar.elfeed because it is ignored on A.  Then on
B, you did "mv foo baz", and then ran unison.  But I'm guessing, so
please give a reproduction recipe that is based on but simpler than your
actual problem.

One approach might be to make removing a directory fail if it is
non-empty (with the files that are supposed to be recreated moved
first).  This will turn your data loss scenario into an annoyance for
many, but that seems reasonable.  It is reasonably likely that it is a
small change, basically rmdir instead of rm -rf, or just declining to
enumerate and clean up.  It's also reasonaly likely that it will cause a
lot of complaints.

> This suggestions seems to me to have good cost-benefit.  I cannot help
> with implementation, but maybe I can help with testing.  I am on Gentoo
> GNU/Linux using unison 2.51.5 (ocaml 4.14.1).

You should get updated to the most recent release at least, to be ready
to help, and because 2.51.5 is too old for bug reports or help.
(However, I do not think there are significant changes related to your
problem.)

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