Thanks for the comments. What about a directory? Part of the logic here was looking for and ignoring directory change when deleting files I think. Should it use mtime for directory only in that case? Is the mtime versus ctime security concern still relevant for a directory? Can you elaborate on the concern?
I've reverted to standard tar to find the case again. When I was originally debugging this I was seeing ctime change by some small amount (can't remember the values) and there was nothing accessing the system other than McAfee on access scanner maybe. It was a serial job that copied files to a location then ran tar, so there would be nothing else interacting with the files. Hopefully I can reproduce the issue again and then get better information on why it did this. The option to ignore change is useless as tar still exits with an error. This will kill a build pipeline and the effort to determine that the error is for something you are ignoring is significant and sometimes even impossible. Maybe an option to have tar not exit with error for this case, not just ignore the error and exit with an error code... Cheers, Mark. > On 3 Dec 2015, at 3:30 AM, Paul Eggert <[email protected]> wrote: > >> On 12/01/2015 11:19 PM, Pavel Raiskup wrote: >> FYI:https://lists.gnu.org/archive/html/bug-tar/2015-10/msg00021.html > > In particular, see: > > https://lists.gnu.org/archive/html/bug-tar/2015-10/msg00025.html > > Most likely this is a bug in Mark's file system, not in tar. Tar can't rely > on mtime here, as applications can modify mtime to whatever they want. >
