Re: [bug #46815] problem when testing file size

[Assaf Gordon]

Hello all,

> On Jan 10, 2016, at 17:43, James Youngman <address@hidden> wrote:
> 
> On Sun, Jan 10, 2016 at 7:23 PM, Bernhard Voelker
> <address@hidden> wrote:
>> On 01/09/2016 04:41 PM, James Youngman wrote:
>>> Let's re-open the discussion about what to call the "sane" alternative to
>>> -size, and implement it this time.
[...]
> 
> Suppose someone wants to find files smaller than 20MiB.  Are you sure
> that the best answer we should give them is that they should use
> "find -size -20971520c"?

Some what similar, how about the following heretical patch (attached).

With this patch, when using "-size" with K/M/G suffixes *and* 
greater-than/less-than option behave as if the block-size is 1 and the user 
entered the explicit byte value? 

It is not backwards-incompatble, but more closely resembles what users would 
naively expect.
It also does not break the POSIX wording (if one reads it in a strict way, 
where the rounding-to-next-integer applies only to blocks, and not to other 
suffixes).

With it, the "help" section should become simpler:
When c/k/m/g suffixes and greater-than/less-than option - it behaves exactly as 
one would expect.
Without suffix (using 'blocks') - it rounds to next integer value.
The remaining option to improve/change is the "exact" option with a suffix - 
which can be further debated.

0001-size-avoid-block-size-rounding-with-k-m-g-suffixes-t.patch
Description: Binary data

(note: this is not well tested, just an quick poc).

What do you think?
regards,
 - assaf