Retention cleanup on a 400k-file spool

The command substitution is expanded unquoted, so its output is split on IFS and then each word undergoes filename generation before rm sees it:

• Data loss / wrong targets. A name containing a space becomes two arguments; a name containing * or ? expands against the current directory; the file literally named -rf is parsed as options. rm -f swallows the error for the harmless cases and quietly deletes the wrong things for the rest.
• Failed runs. 400k names in one argument vector blows past ARG_MAX (Argument list too long), and ls on that directory is slow enough to overlap the next cron run.
• Wrong policy. ls -t | tail -n +100000 means 'keep the newest 99,999 entries' - retention by count, not by age. A heavy feed day deletes too little; a quiet day deletes files that are hours old. It also matches directory names, and it sees only the top level, so the month subdirectories are never considered.
• Cosmetic but real. -f masks failures, so cron's mail is silent and nobody learns the job is doing nothing.

Every fault above is a correctness problem, not a style problem. The only defensible pieces are cd as a guard and running as the unprivileged spool user, which limits blast radius.

find /var/spool/incoming -xdev -type f -mtime +30 \
  ! -name '*.keep' \
  ! -path '/var/spool/incoming/index' \
  ! -path '/var/spool/incoming/index/*' \
  -delete

Justification:

• -type f restricts to regular files, so directories and the symlinks under latest/ are never candidates. find does not follow symlinks by default (-P), so the NFS export is not traversed; never add -L here.
• -xdev stops at a filesystem boundary, in case anything is mounted inside the spool.
• -mtime +30 is not '30 days or older'. GNU find truncates the age to whole 24-hour periods and +30 means that truncated value is greater than 30 - i.e. 31 days or more. A file 30 days and 20 hours old is not matched. If the policy means an exact 30-day boundary, use -mmin +43200. Also note that a file with a future mtime never matches +30.
• -prune cannot be used with -delete. -delete implies -depth, and under -depth find processes a directory's contents before the directory, so -prune has no effect. Excluding by -path with a negation works in both modes.
• Negated *.keep rather than -prune: same reason, and it also catches keep-files inside the month subdirectories.
• The leading-hyphen names are safe. find emits paths with the starting-point prefix (/var/spool/incoming/-rf), so no argument can be read as an option. That is a property of find, not of rm; if you must pipe to rm, use -print0 | xargs -0 rm --.

Space that find cannot see comes from one of a few places; check in this order:

1. Deleted-but-open files. lsof +L1 /var/spool/incoming (or lsof | grep -i deleted). An ingest process still holding an unlinked 40 GB file keeps the blocks allocated; du cannot see it, df counts it. Fix by restarting the holder, not by touching the spool.
2. Future mtimes. The sender controls timestamps; a clock running ahead produces mtimes in the future, which -mtime +30 never matches and -mtime -1 happily does. Confirm with find ... -newermt 'now' -printf '%TY-%Tm-%Td %p\n' | head.
3. Files below a mount or inside a directory the pattern excludes. mount | grep spool, and find /var/spool/incoming -xdev -type d -newer /var/spool/incoming -maxdepth 2 | head to spot unexpected tree shapes.

Validation before enabling cron: run the identical find with -print instead of -delete, log a count (... -print | wc -l) and a sample, compare against the previous day's count, and only then switch the predicate. Keep the count in the cron output so a silent zero or a million is visible, and keep spool as the executing user so a mistake cannot reach outside the spool.