On Jan 6, 2015 10:14 AM, "Eric Blake" <[email protected]> wrote: > > On 01/05/2015 11:08 PM, Phil Miller wrote: > > On Fri, Jan 2, 2015 at 7:48 PM, Eric Blake <[email protected]> wrote: > > > >> On 12/29/2014 04:49 PM, Phil Miller wrote: > >>> * find/defs.h (struct options): Add a 'sort' flag. > >> > >> A boolean flag is insufficient. The default should remain unsorted, but > >> you should offer the ability to sort by either name or inode, which > >> means -sort needs to take an argument to say which sorting method to use. > >> > > > > The motivating use case for this patch is in enumerating files in a stable > > order, from <https://bugs.debian.org/719845>. Sorting by inode doesn't > > offer that benefit, since it will vary every time a given tree is > > generated. > > Just because YOU don't plan to sort by inode does not rule it out as a > useful sort. Coruetils proved that it is MUCH faster to implement 'rm > -r' when visiting a hierarchy sorted in inode order than it is in > unsorted or name order - so there ARE operations where finding names in > inode order will provide speedups to some clients.
Ok, that's the sort of motivating detail I was wondering about. > > > I can imagine a potential performance benefit to downstream > > consumers in sorting by inode (putting subsequent disk access in roughly > > consecutive order), but I don't see much payoff in implementing it without > > some more concrete motivation. That said, if it will smooth integration, > > it's easy enough for me to just go ahead and implement. > > Gnulib's fts module already provides all three sort orders (unsorted, > name, and inode), so it should be fairly easy to wire up all three > (since we are already using unsorted by default). I'll get this implemented shortly. Thanks for letting me know that FTS provides this - that'll let me drop the wrapper functions I would have written.
_______________________________________________ Findutils-patches mailing list [email protected] https://lists.gnu.org/mailman/listinfo/findutils-patches
