This is very interesting.
Your script executes the following commands in order:
cvs -d ${REPOSITORY} co missing_commit
cd missing_commit
echo "dead1" > file1
There’s nothing in between it.
In one of the “racy” cases, the following happens:
I put in a debug fprintf(stderr, …) with the result of time()
cvs co ⇒ time() returns 1311862167
tg@zigo:~/X $ date -d @1311862167
Thu Jul 28 14:09:27 UTC 2011
tg@zigo:~/X $ stat working/missing_commit/file1
File: `working/missing_commit/file1'
Size: 6 Blocks: 8 IO Block: 4096 regular file
Device: ca00h/51712d Inode: 667057 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ tg) Gid: ( 1000/ tg)
Access: 2011-07-28 14:09:26.000000000 +0000
Modify: 2011-07-28 14:09:26.000000000 +0000
Change: 2011-07-28 14:09:26.000000000 +0000
So the question is rather: why is the file changed with an atime/mtime/ctime
that lies in the past?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/12230
Title:
cvs checkout is racy, it wasn't in the past
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cvs/+bug/12230/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
