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

Jorge P. de Morais Neto <[email protected]> writes:

> Em [2023-07-12 qua 07:59:02-0400], Greg Troxel escreveu:
>
>> I think the answer is probably more or less "because ignored files are
>> not important, by the definition of what should be ignored."
>
> Then I suggest, at least, prominently document this interpretation.

I meant that as an explanation of how this came to me, not that it was
right.

>> 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.
>
> The offending directive was:
>
> ignore = Path unison-stow-folding/emacs/.elfeed/*
>
> As the name suggests, I use Unison to sync my dotfiles between personal
> notebook and my workstation, and GNU Stow to deploy them as symlinks.
> For the Emacs Stow package I used the /folding/ feature of GNU Stow.
> That would make the directory ~/.elfeed itself a symlink to
> ~/unison/unison-stow-folding/emacs/.elfeed.
>
> But I did not want to synchronize everything in ~/.elfeed.  Now I don't
> remember what I thought at the time; maybe I intended to synchronize
> Elfeed's configuration and metadata (such as tags) while leaving out the
> feed database which weighs some dozens of megabytes and didn't need to
> by synchronized via unison.  I now realize I should have left ~./elfeed
> out of unison.

If the actual .elfeed data were in path that was never under the sync
root, and it was just a symlink that was synced, then this would have
been ok.  Once again this is just my approach: do not sync paths unless
you basically want to sync everything under it.

> Then recently I reorganized my dotfiles GNU Stow packages, and this
> triggered the data loss.  *If* I remember correctly, on my workstation
> (which indeed didn't have Elfeed's database synchronized) I have renamed
> ~/unison/unison-stow-folding/emacs/.elfeed
> to
> ~/unison/home-stow-folding/all::emacs/.elfeed
> then synchronized it to my laptop.

I see.  It might be helpful if you can create a script to reproduce the
loss, operating on two replicas locally.

>> 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.
>
> Maybe you could add a "cautious" command line option or configuration
> directive?

One problem is that we already have too many options.  Without counting
or thinking, I think it would be good if we could get rid of half of
them.

And, to avoid this problem, it needs to be default.


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?

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