Import the notes for 0.4.0 through 0.7.0 verbatim from the GitHub
releases, reconstruct notes for the untagged-on-GitHub 0.1.0 and 0.3.0
from the git history, add an index page and wire everything into
SUMMARY.md.
* find: skip broken pipe errors in wasm executions
* find: report non-broken-pipe write errors instead of swallowing them
flush() only checked for BrokenPipe, silently ignoring other errors
(e.g. ENOSPC). Add regression tests for both cases.
locate compared the database age against --max-database-age using
`TimeDelta::days(config.max_age as i64)`. chrono's `TimeDelta::days` is
the panicking constructor, so a large but syntactically valid value
(e.g. --max-database-age 1000000000000) aborted the process with exit
101 instead of being handled.
The `as i64` cast was wrong for values above i64::MAX as well: usize::MAX
wrapped to -1, so a freshly built database was reported as "more than
18446744073709551615 days old (actual age is 0.0 days)".
Guard both conversions and treat an age that i64/chrono cannot represent
as never exceeded, which matches what GNU locate effectively does -- it
truncates the value into an unsigned int, so a huge age simply never
warns. The check moves into an `is_db_too_old` helper so it can be unit
tested.
The -newerXY parser used an unanchored regex, so tokens such as
-neweraBcmty were accepted as a truncated -neweraB. Require an exact
-newerXY match, report unknown predicates with GNU wording, and cover
the issue #782 cases in unit and integration tests.
Signed-off-by: Alex Chen <l46983284@gmail.com>
chrono's %.f drops the fraction (and the leading dot) entirely when the
sub-second part is zero, while GNU find always prints a dot followed by
ten fractional digits. Use an explicit .%f0 so whole-second timestamps
format the same way as GNU.
Sizing command lines all the way up to ARG_MAX made execvp() fail with
E2BIG: the kernel also charges the argv/envp pointer arrays against the
limit, which the character count does not account for. Follow GNU xargs
and use at most 128 KiB per command line by default, and use a
saturating subtraction so a tiny ARG_MAX cannot underflow.
The cap only applies when no explicit -s was given: like GNU, an
explicit -s may still raise the limit up to the system maximum.
The -newerXt options parsed the year with `.parse().unwrap()`, but the
capturing regex's `\d{4}` matches Unicode decimal digits while
`str::parse` accepts only ASCII. A year of four non-ASCII digits
(e.g. `jan 01, ٠٠٠٠`) passed the regex and then panicked, aborting with
exit 101. Fold the failed parse into the existing None path so it
reports the GNU-style "I cannot figure out how to interpret ..." error
with exit 1, as uutils already does for other malformed dates.