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.)