In the section of /usr/sbin/cron-runs lastrunfile="${LASTRUNDIR}/cron.${BASE}" if [ -e "${lastrunfile}" ] ; then case $BASE in hourly) #>= 1 hour, 5 min -=> +65 min TIME="-cmin +65" ;; daily) #>= 1 day, 5 min -=> +1445 min TIME="-cmin +1445" ;; weekly) #>= 1 week, 5 min -=> +10085 min TIME="-cmin +10085" ;; monthly) #>= 31 days, 5 min -=> +44645 min TIME="-cmin +44645" ;; esac find "${LASTRUNDIR}/" -name cron.$BASE $TIME -exec rm {} \; 2>/dev/null || : fi "-cmin" is used to filter the files. According to the documentation I found -cmin is for the date/time when the _inode_ data of the file has changed. The file in question is an empty file and on my system with btrfs the files never showed up with this filter. I assume btrfs does not provide the inode information if there is no data in the file. (When I entered some text in the file the -cmin filter was working.) When I replaced -cmin with -mmin the removal of the stale files worked as expected.
post the output of `stat` on the file. the content doesn't really matter ... a file has a creation time regardless of what's in it. there aren't diff timestamps for the file content and the file metadata.
I can no longer reproduce the issue. The output of stat shows normal values for "Modify" and "Change". I should have tried that before. I think the issue can be rejected. Thanks for your reply!
feel free to re-open if you can gather info. glancing at the code, it has logic to self-heal if your clock was set in the future and then pulled back. not sure what other edge case could come up.
