On 05/12/11 20:04, Robert Morell wrote: > this updates the "file > changed" logic to explicitly check the file status fields that tar > actually cares about, and ignore the problematic ones that it doesn't.
Unfortunately that won't work in general, since it's possible that the file was removed and recreated, with the same inode number as before. Checking the ctime catches this situation. Ignoring the ctime would miss it. This is a common strategy among archiving programs. Arguably POSIX allows a kernel to change the timestamp of a file whenever it pleases. That does not mean it's a good idea. Perhaps instead of modifying the programs that look at time stamps, you could fix 'ld' so that it does an msync with MS_ASYNC before it exits? If what that mailing list says is correct, that should fix the problem for programs like 'tar' that look at ctime.
