> [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
