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

There is a class of files which are preferably deleted - I have these,
among others similar, in my profile:

ignore = Name temp.*
ignore = Name *~
ignore = Name ~*
ignore = Name .*~
ignore = Name *.tmp
ignore = Name *.BAK
ignore = Name *.bak
ignore = Path */tmp

They are not worth syncing, but it would be annoying for these remnants to
be left behind after every directory move. To me, it would make sense to
distinguish files of this type from valuable files which should not be
synced when constructing the profile. So, instead of 'ignore =' to have
'ignore_junk=' for this type, and 'ignore_valuable=' for others. Let junk
be deleted silently, but not the valuable files. These are perhaps not the
best names, but I think that might resolve the problem.

If the behaviour of 'ignore' was updated to have the new safer behaviour,
it would take little effort to modify old profiles to use 'ignore_junk'
when it would be more convenient.

cheers,
Greg


On Fri, 14 Jul 2023 at 02:52, Greg Troxel <[email protected]> wrote:

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

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