preventing tmpwatch from clobbering archives that were "just" unpacked into /tmp

I have an application that unpacks an archive into /tmp, restoring the extracted files' modification and access times. Sometimes these files and the enclosing archive are many years old. After the files are extracted (sometimes many minutes or hours later), the unpacking software will selectively use/modify some of the files. Once its done, the application will remove the extracted files/tree. This operation can happen any time of the day (e.g., at times when tmpwatch is run by cron).

Every so often, the application will freak out because it can't find a file that it knows it has recently unpacked. What I think is happening is that tmpwatch is descending into the unpacked tree after when atime/mtime is adjusted (by unzip or tar that is driven by the application) to the distant past but before the application can access the relevant file. Since tmpwatch is by default looking at atime, it thinks the file is decrepit and removes it.

Arguably, the unpacking could be done elsewhere or the application could use appropriate flags to not reset the timestamps to the past. However, neither of those approaches is viable for various reasons.

I think I might be able to modify the tmpwatch cron script to take all of this into consideration (and make the most conservative decision regarding removing the files) by specifying the --ctime argument as well as --mtime (and the previously implied --atime). I'm a bit confused by the term "maximum of these times" used in the tmpwatch man page, though -- my initial reading (until I looked at the C source and thought otherwise) was that it took the maximum of the differences (meaning that it was more liberal in removing things). Does it actually mean "latest of these times" (and thus tmpwatch will leave alone files that were just unpacked as their inode was only recently touched)?