[it's customary to reply inline, rather than top-posting, on technical lists]
On 04/05/2010 03:13 PM, [email protected] wrote: > Thank you very much for your kind and accurate answer! I have tried to > modify my patch so as to solve the problems you pointed at. I know that > looking at the content of a file is not in the spirit of find, but anyway > I believe it is a very useful exercise for me to go and hack such an > excellent piece of software as findutils is... and moreover I would be > glad to bring some little collaboration to the GNU project. > > As to the documentation and the regression tests, I have not yet worked on > them, but surely will in the next days. 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. >> >> I hope you find the feedback above helpful; I'm certainly glad to find >> a volunteer willing to work on findutils. Having said this, I'm not >> certain that making such a check this way is really better than using >> "-exec cmp". Considering after all that this is a substantial amount >> of extra code. However, someone else from the list may well have an >> opinion different to my own. 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. -- Eric Blake [email protected] +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
