Hide Forgot
Recently, Cron sent me this little tidbit: > Subject: Cron <root@proxy> /usr/sbin/tmpwatch 2400 /tmp /var/tmp > >error: error: error: error: error: failed to lstat /tmp/sort0388800000: No such file or directory >failed to lstat /tmp/sort0388800001: No such file or directory >failed to lstat /tmp/sort0388800002: No such file or directory >failed to lstat /tmp/sort0388800003: No such file or directory >failed to lstat /tmp/sort0388800004: No such file or directory As it turns out, these files went away between tmpwatch reading the directory and checking each file. There's no reason to report this kind of error, is there? After all, these are *temporary* files, subject to removal at any time by the program that generated them. Also, I don't know if this next problem has ever been fixed since 4.2, but tmpwatch will never, ever delete an empty directory, because in the process of checking the directory for files, the atime gets changed. So tmpwatch needs to save and restore the atime for any sub-directory that it checks. John Van Essen <jve@gamers.org>
This is being assigned to a developer for further review.
you may now specify a --quiet or -q option to tmpwatch to make it not warn you about these errors, if you prefer. It is really a preference thing. Also, I have taken over maintenance of tmpwatch and fixed the other bug you reported where directories were never removed because their time was always getting updated. The directory atime and mtime are now restored after it is finished being processed. These features are in tmpwatch-1.6-1 and later.