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

On Sat, 15 Jul 2023 at 14:33, Greg Troxel <[email protected]> wrote:
>
> 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.

Time for a summary. We have four different cases here.

A. "Prentend it's not there" aka "Don't sync; ok to delete when a
synced parent is deleted"
This means a synced parent dir is deleted blindly with all its contents.
Use case: think of rules like ignore = Name *.tmp and ignore = Name .~*

B. "Don't sync; don't touch in any way"
This is a combination of A and C.

C. "Sync; don't delete under any circumstances"
This means that deleting a parent dir must not delete these specific children.
Use case: syncing by fsmonitor, but wanting to inspect all deletions manually

D. Unsynced files that don't fall under any of A, B, C. In other
words, files that would have be synced if the parent hadn't been
deleted in the other root.
Use case: full bilateral sync (the "normal" case)

(note: _currently_, renaming also means deletion)

Cases A and D are already implemented. Case C seems like it should be
implemented; the fact that it doesn't work as expected is quite
certainly a bug. Case B is what you have proposed to implement.

I think all of these cases make sense and case A does not need to be
removed to implement case B. Implementing case B and fixing case C is
almost entirely the same code. There is nothing to be gained by
removing case A other than reducing choice for users (which, I admit,
also has its place, just maybe not here). Too many preferences is
certainly a problem but we have room to play within the "ignore"
preference. For example, next to 'ignore = Name myfiles' we could have
'ignore = Name_nodelete myfiles', or the opposite (just a wild
thought, let's not get stuck on this).

> I don't see that noupdatepartial is relevant to
> deletions.

"update" means modify or delete for these preferences.

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