[Top][All Lists]
[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