bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch that adds a new test to find


From: address@hidden
Subject: Re: Patch that adds a new test to find
Date: Thu, 8 Apr 2010 19:01:45 +0200

> [it's customary to reply inline, rather than top-posting, on technical
> lists]

Please excuse me, and thank you for the remark.

> One other thing that you need to be aware of - your patch is large
> enough that we cannot incorporate any of it into findutils unless you
> first assign copyright to the FSF.  If this is something you are
> interested in pursuing, then we can give you details off-list on how to
> proceed.  The process typically takes a couple of weeks.

Of course I am ready to assign copyright to FSF.  Please note however, that my 
own code is really a very small portion of the patch... most of it is taken 
almost verbatim from GNU diffutils.

> I can see the potential for savings here; particularly if the comparison
> file can fit into memory, because then you not only have fewer processes
> due to -exec cmp, but also the potential for fewer disk accesses (each
> separate cmp process would reread the file, while doing it in find could
> just reuse the one in memory).  I don't know if you are taking the
> shortcut of comparing file size, and skipping the comparison altogether
> if the candidate file and the comparison file are different sizes, but
> that is certainly an optimization worth considering (although for
> non-regular files, such as in /proc, file size is not an accurate measure).
>
> But it's still not something that I've ever found myself needing to do,
> so I'm still on the fence on whether this makes a good addition.

My choice has been not to read the whole reference file into core, but only the 
first few blocks... this I think is sufficient, and moreover it takes into 
account the possibility that the user specifies several references file, such as

  find -samecontent file1 -o -samecontent file 2 -o -samecontent file3 -o ...,

which could possibly saturate the available memory.

Thank you for your kind suggestions,
Roberto Reale





reply via email to

[Prev in Thread] Current Thread [Next in Thread]