O problema não está relacionado ao operador -and
, mas à sintaxe não intuitiva do argumento -size
. O argumento não é um tamanho máximo dado com uma unidade, mas um número máximo e uma unidade na qual o cálculo é realizado. O teste -size -1k
não significa “menos de 1kB”, mas “o número de kB (arredondado) é menor que (e não igual a) 1”. Portanto, -size -1k
corresponde apenas a arquivos de tamanho 0 e, da mesma forma, a -size -1M
, -size -1G
, etc.
Para corresponder arquivos com 2 30 bytes ou menos, use -size -2G
, ou -size -1025M
, etc. (observe como -2G
não é equivalente a -2048M
). Como alternativa, use ! -size +1G
- um tamanho com o modificador +
significa “estritamente mais do que esse tamanho”. Para corresponder arquivos com 2 30 -1 bytes ou menos, use -size -1073741824c
.
Eu acho que o motivo pelo qual -size -NUMBERUNIT
é tão estranho é a compatibilidade histórica com -size -NUMBER
, que contava blocos; arredondamento faz sentido, pois um arquivo que ocupa, e. 7.5 blocos estão efetivamente ocupando 8 blocos com o último bloco não preenchido. Portanto, -size -8
significa “ocupar 7 blocos ou menos”. Adicionar uma unidade funciona como se ela estivesse fazendo o tamanho do bloco, então -size -8k
significa “ocupar 7kB ou menos”.
(Esta resposta é sobre o GNU find - algumas outras implementações se comportam de maneira diferente, e o POSIX não padroniza outras unidades além de blocos e bytes.)