bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #62089] find -size -1024k different from -size -1M


From: Stephane Chazelas
Subject: [bug #62089] find -size -1024k different from -size -1M
Date: Wed, 23 Feb 2022 11:27:03 -0500 (EST)

Follow-up Comment #3, bug #62089 (project findutils):

That's an extension on the standard POSIX behaviour. c is the only suffix
supported by POSIX find -size. Without suffix, the unit is 512 byte blocks
(formerly commonly known as sectors).

-size n: matches on files whose size rounded up to the next integer number of
512 byte units is exactly n. For instance, -size 2 selects files with sizes
513 to 1024 bytes.

-size -n: when that number is strictly less than n. So with -size -2, that's
files with sizes 0 to 512 bytes

-size +n: when that number is strictly more than n. So with -size +2, that's
files with size of 1025 bytes or more.

GNU find extended it with more suffixes (kmg...) but with the same semantic.
Same happens in zsh with its L glob qualifier: *(LM-2) matches on files with
size 0 to 1048576.

FreeBSD find also added suffix support in 2006, but while it honours the POSIX
rule for -size n without suffix, with suffixes, it uses the more intuitive
semantic where -size 10M is the same as -size 10485760c. 

I agree the GNU behaviour is more confusing and unintuitive, but it's too late
now to change the semantic. It would mean not being standard compliant for
suffix-less numbers and it would break backward compatibility (though it's
likely it probably would also fix some scripts which expect the more intuitive
behaviour)

What could be done is introduce new syntax with a different semantic. For
instance, we could have -size '<=10MiB' to match on files that  are less than
10MiB. Or we could have a new -apparent-size '-10M' with the more intuitive
API. I'll let the GNU find maintainers comment on whether they would consider
doing it.

Note that there's a similar problem with -atime/-mtime... where -mtime +n
matches on files whose age rounded *down* to the next integer number of days
is strictly greater than n.  So for instance -mtime +1 matches on files that
are over *2* days old, not one, because a file that is 47:59:59.999999 days
old is rounded down to 1 day which is not *strictly* greater than 1.

Again, both GNU and FreeBSD find support suffixes as extension, but again with
different semantics.

For those though, there is already a different (non-standard) API that we can
use with a more intuitive API: ! -newermt '1 day ago' as a more intuitive
equivalent to -mtime +0 (same as FreeBSD's -mtime +1d or
+24h/+1440m/+86400s).

The -newermt was originally from BSD.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62089>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]