Re: Bug in find's -size (+patch)

[James Youngman]

On Sun, Feb 06, 2005 at 04:01:36PM -0500, Amir Sela wrote:

> Well, it's not just for me. I can fix it for myself and be done with
> it.

True.  That's one of the great things about Free Software.

> It's simply broken. There's no other way to put it.

Well, it complies with both the POSIX standard and historic usage of
"find".  I might concede that under some circumstances the current
behaviour is _inconvenient_, but I find it hard to agree that it is
_broken_.

> In any case, according to the reference you gave, it seems that 'k' is a
> GNU extention anyway, which means we only need to preserve the broken
> part when it's on 'b'. Will you apply a patch that will do that if I
> submit it? 

No.  I think that violates the principle of least surprise.  People
expect that changing the suffix changes only the multiplier, and won't
change the semantics of the predicate itself, I think.

> Assume that I'll submit a patch that will add 'm' (for megabyte)
> support, 

But 'M' is already provided.  

> and the code for comparison doesn't change. You'll get +/-1MB
> inaccuracies in the results. 

Are you saying that you would prefer there to be a test which would
match only if the size of the file is an exact multiple of 1048576
bytes (in the case of m/M)?  That doesn't seem that useful to me.
Also if you want to select files which are an exact number of bytes,
you can do it this way for example:-

  find . -size $(expr 6 '*' 1024)c -print

... which will only match files which are exactly 6144 bytes in size.
If this doesn't meet your requirement, what exactly did you have in
mind?

> I think we should confine this POSIXLY CORRECT (and broken)
> behaviour as much as we can, rather than let it cascade into GNU
> extensions.

I disagree; size suffixes should change only the multiplier on the
number to which they are applied, and not modify the semantics of the
test in which they are used.  However, there is still scope for having
a new _prefix_ for the number, which normally does affect the
semantics of the match (as do + and - for example).  If there's a
coherent and useful alternative that does what you want, it would be
possible to use a new proefix to accomodate that.

James.