Re: Revisiting "file changed as we read it", with a proposed patch

[Martin Simmons]

>>>>> 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