[pca] xref aged 1603 considered up to date?

[Martin Paul]

Glen,

> This does not seem right to me.  Am I missing something? Isn't the number of days since last December less than 1603? I thought pca would download a new xref file if the one it found was over 1 day old.
>
> xref mtime: Thu Dec 20 20:45:08 2012
> xref now  : Wed Oct 30 10:20:58 2013
> xref ctime: Wed Oct 30 09:54:15 2013
> xref age  : 1603

The "age" here is the difference between "xref now" (the current time) 
and "xref ctime" (the file/inode change time) in seconds. If it's more 
than 3 hours (10800 seconds), pca will download the xref file. "xref 
mtime" is the original modification time of the xref file.

It's been a long time since I wrote that code, and I remember that it 
took me a long time to get this right. The goal was to ensure that PCA 
always works with a current xref file; it's not very efficient to 
download the xref on every PCA run, though.

Sun/Oracle updates the file once per day. In the beginning, I tried to 
find out the time of day the update happens and hard coded it into PCA, 
so it updated the xref file exactly once per day. That didn't always 
work, and things got complicated when Sun/Oracle wasn't the only source 
of the xref file anymore, after support for local proxy etc. was added.

I then made PCA maintain the original modification time of the xref 
file, as this is what's shown when doing an "ls -l". It would have been 
very confusing, if PCA updated that timestamp. So I'm using the ctime as 
a marker which notes when PCA last tried to update the file. If it has 
done so in the last 3 hours, it does nothing. Otherwise it downloads the 
"new" xref file and then compares the timestamp in the file (header 
line), and only uses the fresh file if it's really new.

Like that, PCA usually gets the current xref file when I run it for the 
first time in the morning, but subsequent runs to download or install 
patches just use the file and don't re-download the file in the next 3 
hours.

Martin.