On Monday 18 January 2016 17:33:54 Pádraig Brady wrote: > On 18/01/16 16:25, Pádraig Brady wrote: > > On 18/01/16 16:10, Kamil Dudka wrote: > >> On Monday 21 December 2015 15:01:56 Kamil Dudka wrote: > >>> On Monday 21 December 2015 00:05:51 Pádraig Brady wrote: > >>>> On the other hand we've had no reports of issues with the > >>>> existing auto config done by FTS. > >>> > >>> Because the leaf optimization has been enabled for reiserfs only until > >>> now. > >>> I suspect that NFS will not be that easy and such file system issues > >>> might > >>> be difficult to debug without the -noleaf option actually implemented. > >> > >> So we have the first bug report about the leaf optimization causing > >> problems to users of find(1): > >> > >> https://bugzilla.redhat.com/1299169 > >> > >> Is this a reason to implement the -noleaf option of find (and > >> consequently > >> the FTS_NOLEAF flag of gnulib's FTS)? > > > > Maybe. But I'm also thinking it might mean we > > can't enable this optimization for NFS > > as the implementations are too disparate in this regard? > > > > It seems prudent for example to disable this > > optimization for the imminent coreutils 8.25 release :( > > Patch attaced
Looks good for coreutils needs if there is a new release behind the door. Now I need to have a closer look at how such cases were handled by findutils before it was rewritten to use FTS. The recursive implementation of find has the leaf optimization enabled by default but it supports an error recovery for cases like this. It still works in RHEL-5 and nobody has reported such assertion failures yet... Kamil
