The problem isn't related to the -and
operator, but to the unintuitive syntax of the argument of -size
. The argument is not a maximum size given with a unit, but a maximum number and a unit in which the calculation is performed. The test -size -1k
does not mean “less than 1kB” but “the number of kB (rounded up) is less than (and not equal to) 1”. Thus, -size -1k
only matches files of size 0, and likewise for -size -1M
, -size -1G
, etc.
To match files that are 230 bytes or less, use -size -2G
, or -size -1025M
, etc. (observe how -2G
is not equivalent to -2048M
). Alternatively, use ! -size +1G
— a size with the +
modifier means “strictly more than this size”. To match files that are 230 -1 bytes or less, use -size -1073741824c
.
I think the reason why -size -NUMBERUNIT
is so weird is for historical compatibility with -size -NUMBER
, which counted blocks; rounding up makes sense since a file occupying e.g. 7.5 blocks is effectively occupying 8 blocks with the last block not filled up. Hence -size -8
means “occupying 7 blocks or less”. Adding a unit works as if it was making that unit the block size, so -size -8k
means “occupying 7kB or less”.
(This answer is about GNU find — some other implementations behave differently, and POSIX doesn't standardize units other than blocks and bytes.)
-size -1M
&-size -1G
as0
varies by platform. GNU find does this, BSD find does not. Logically, it's hard to argue that "less than2^20
" means0
!? – jeberle Aug 12 '16 at 19:06