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

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

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

An explanation not aspirational.  And I don't think warn is good enough;
I think we need "just won't".


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

yes, but the permanent loss is a conceptual bug, not a consequence of a
crash  in the middle.[q
>
> 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 can't even follow this.  That's more about me, being a bit tired this
minute.  But things are already too complicated.

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

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

  hope this is better, and learn what the trouble is

  do something else later, maybe
  

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