>>>>> On Thu, 2 Jun 2022 17:06:32 -0700, Paul Eggert said: > > 1. If the mtime or size changes, doesn't this necessarily mean that > ctime changes? In other words, isn't tar's current test for size growing > redundant? This test was added in commit > c455373e5b7fc3037ad9e4204ba6c6aac2faa10f dated Oct 14 21:11:27 2006 > +0000 but it's not clear to me why it is needed now.
I think the check for size is needed because the ctime may have lower granularity than the speed of size change, e.g. on some old system: $ echo > /tmp/foo; echo ==before; stat /tmp/foo; usleep 500; echo foo >> /tmp/foo; echo ==after; stat /tmp/foo ==before File: `/tmp/foo' Size: 1 Blocks: 8 IO Block: 4096 regular file Device: 805h/2053d Inode: 1288664 Links: 1 Access: (0666/-rw-rw-rw-) Uid: ( 597/ martin) Gid: ( 100/ users) Access: 2022-06-06 11:49:20.000000000 +0100 Modify: 2022-06-06 11:49:49.000000000 +0100 Change: 2022-06-06 11:49:49.000000000 +0100 ==after File: `/tmp/foo' Size: 5 Blocks: 8 IO Block: 4096 regular file Device: 805h/2053d Inode: 1288664 Links: 1 Access: (0666/-rw-rw-rw-) Uid: ( 597/ martin) Gid: ( 100/ users) Access: 2022-06-06 11:49:20.000000000 +0100 Modify: 2022-06-06 11:49:49.000000000 +0100 Change: 2022-06-06 11:49:49.000000000 +0100 Also, the FAT filesystem only stores the "create time". On FreeBSD's msdosfs, this is mapped to the birthtime and the ctime always equals the mtime. __Martin