Re: cvs up slowdown

[James Cloos]

>>>>> "Mark" == Mark D Baushke <address@hidden> writes:

Just to be sure everyone following this is up to speed, I should point
out the difference between the posix and right zonefiles:

Posix has chosen to ignore leap seconds (for some definition of
ignore; see below) and so the posix/ zonefiles -- which are also the
default set -- do not incorporate leap seconds.  The zonefiles under
right/, OTOH, do.  So unless you use a zonefile under right/ the
time will be several seconds off from 'official' time.  (Currently
posix/UTC is 23 seconds ahead of right/UTC.)

Also, you'll need a dist that installs the right/ zonefiles in order
to play along.  Not all do -- I understand the BSDs no not -- but at
least most of the Linux dists do.

Oh, and just to be clear, I do not use NFS.  This is all on a single
laptop.

>> Looks like the problem stems from the use of a right/... timezone
>> instead of a posix/... timezone.  The UTC-vs-posix difference
>> skewed the seconds of the timestamp in Entries.

Mark> The timezone in use is UTC.

I could see from inspection that the Entries files at least attempted
to have UTC, but the timestamps there and in the inode do not match if
the checkout or update was run in a right/ timezone.  And the
difference is exactly 23 seconds:

,----
| :; (unset TZ; /bin/ls -l --full-time ChangeLog; egrep ChangeLog CVS/Entries )
| -rw-r--r-- 1 root portage 19712 2006-05-18 15:38:27.000000000 +0000 ChangeLog
| /ChangeLog/7.92/Thu May 18 15:38:04 2006//
`----

(/etc/localtime is linked to UTC, which is the same as posix/UTC.)

Compare that with:

,----
| :; (env TZ=right/UTC /bin/ls -l --full-time ChangeLog; egrep ChangeLog 
CVS/Entries )
| -rw-r--r-- 1 root portage 19712 2006-05-18 15:38:04.000000000 +0000 ChangeLog
| /ChangeLog/7.92/Thu May 18 15:38:04 2006//
`----

So, either the timestamp in the Entries file is wrong, or the timestamp
provided to the_logical_equivalent_of_touch(1) is wrong, or there is a
bug in glibc that shows up when using a right/ zonefile.

I presume the timestamp is sent in text over the pserver protocol,
yes?  And that is used as-is in the Entries file?  How is that then
converted to seconds-since-the-epoch for the purpose of setting the
timestamp in the inode?  Either that, or the libc function called to
set the inode's timestamp would seem to be the weak point.

-JimC
-- 
James Cloos <address@hidden>         OpenPGP: 0xED7DAEA6