> I can't believe that tar would compare the actual data contents. > > Without looking at tar's code for other approaches, I suspect that > tar checks the file's inode contents before and after copying the > file. If this is the case time stamp, file owner/group id, size, > or permission changes could all trigger the message. >
Yes, that's probably what it's doing. I still can't see what might have triggered this message for those 2 particular files and not the other ones from the same oracle cold backup. If it's a tar bug, I simply hope it's not preventing the files from being correctly backed up. I have recovered the files somewhere else to compare them with the files saved by my previous backup solution. The files are identical. They are also identical to the original file on disk. And they have been backed up at different times. 4h57 for my previous backup solution, 4h30 for amanda, with the files being backuped around 5h11... Thinking of it: What might have happened is that maybe my previous backup solution was reading the files at the same time amanda was estimating it. It might have changed the last "access time" (atime) of the files and triggered the message to gnu tar ???
