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

Dave Warren <[email protected]> writes:

> On 2023-07-12 05:59, Greg Troxel wrote:

>> 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.
>
> I think this needs to be optional to cover all use-cases. I've lost
> data to the current implementation myself. My own fault, I understood
> what I was doing when I set it up.

Why would you want something other than this "don't delete" behavior?

How would you know to set the option, so that if you wanted it or if you
were about to tbe bit by it, the right thing would happen?

> I also really rely on this feature to do some cleanup of
> customer-uploaded files and the unzipped version (in subdirectories),
> but I don't synchronize the subdirectories because I can just unzip
> again if needed. But once a ticket is done, I have 30 days to delete
> everything, so it is great to just nuke a ticket's root directory and
> have the rest vanish.

so you mean to rely on having files in the other replica that are
ignored deleted?

Wouldn't it be better to unpack things into directories that are not
synchronized, if you don't want them synced?  Or to just let them be
synced?  It feels like a lot of trouble arise from this attempt at
optimization.


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