On Friday, May 24, 2013 6:24:11 am Jilles Tjoelker wrote: > On Tue, May 21, 2013 at 11:06:39AM -0400, John Baldwin wrote: > > On Monday, May 20, 2013 5:47:31 pm Jilles Tjoelker wrote: > > > The below patch allows deleting the pathname given to find itself: > > > > Index: usr.bin/find/function.c > > > =================================================================== > > > --- usr.bin/find/function.c (revision 250661) > > > +++ usr.bin/find/function.c (working copy) > > > @@ -442,7 +442,8 @@ > > > errx(1, "-delete: forbidden when symlinks are followed"); > > > > > > /* Potentially unsafe - do not accept relative paths whatsoever */ > > > - if (strchr(entry->fts_accpath, '/') != NULL) > > > + if (entry->fts_level > FTS_ROOTLEVEL && > > > + strchr(entry->fts_accpath, '/') != NULL) > > > errx(1, "-delete: %s: relative path potentially not safe", > > > entry->fts_accpath); > > > I'm curious, how would you instruct a patched find to avoid deleteing > > the /tmp/foo directory (e.g. if you wanted this to be a job that > > pruned empty dirs from /tmp/foo but never pruned the directory > > itself). Would -mindepth 1 do it? (Just asking. I have also found > > this message annoying but most of the jobs I have seen it on probably > > don't want to delete the root path, just descendants.) > > -mindepth 1 works, as does cd /tmp/foo && find . -... (-delete silently > ignores . and ..).
Right, my only concern is that this fix will introduce a change in behavior that I think might be significant, so we should make sure to advertise it well in UPDATING, etc. -- John Baldwin _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
