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

[Bernhard Voelker]

On 01/11/2016 12:43 AM, Assaf Gordon wrote:
>> 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"?

Although this is inconvenient, there are several ways for the user to
avoid doing the math himself.

  # shell arithmetic expansion
  find -size -$((20*1024*1024))c

  # using bc(1)
  find -size -`echo '20*1024*1024' | bc`c
  find -size -$( bc<<<'20*1024*1024' )c

  # using expr(1)
  find -size -$(expr 20 '*' 1024 '*' 1024)c

  # Alternative tools, e.g. du(1)
  du -a --threshold=-20MiB

There are various ways, but I admit that the user intuitively would
maybe want to use the M, G or Tib suffixes.

So the solution is either to combine 'M' and 'c'
  find -size -20Mc
which would be fully backward compatible, or go the way Assaf suggests
and change the meaning of the suffixes M and G:

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

I'd guess that the k, M and G suffixes are not very often used
in scripts - because they didn't "work as expected".
Furthermore, many other GNU tools allow using more fine-grained control
over parameter values using xstrtoimax()-style: different suffixes
(20M alias 20Mib, and 20MB), and a wider range of SI suffixes
(K,M,G,T,P,E,Z,Y).
I must confess I like Assaf's idea, leaving 512-blocks for 'b' (with the
rounding as mandated by POSIX), and otherwise using byte granularity
with proper SI suffixes.

Another topic is file size of sparse files (like du's --apparent-size
option); maybe something like '-size address@hidden'?

Thus said, a new option could fix all the things for the user, but
I'm convinced that it could all be done with -size, too.

Have a nice day,
Berny