file access time in the future

[Tony Coor]

I am seeing file access time on some files with future dates, most commonly Nov 8, 2032. Could this be something going on during backups or possibly a setting in HP/UX that maybe forcing recently accessed files to this date? Can someone do that with commands like touch(1)?

[Mark Grant · Accepted solution]

This a complete guess but I would suggest that inodes with a 34 bit access time are being used to store the acess times from something that had 64 bit ones. I believe that the maximum number of seconds you can fit into a 32 bit access time is around the date you mention. I would suspect your restores or somebody getting a bit to enthusiastic with "touch".

Of course, this IS just a guess.

[Jeff Schussele]

Hi Tony,

I've seen this type behavior from Winblows NT systems with NFS mount or ftp access to an HP server.
Are these files coming from an NT system?
If so there's a patch available from M$ to solve the problem on the NT system.

The *only* way this can be done by the HP system itself is either:
A) System date set improperly
B) the touch -t command.

HTH,
Jeff

[RAC_1]

with touch command you can do that. What is this file? Who owns that? What is the TZ setting for that user?

What is the output of
ls -u "filename"
ls -t "filename"
ls -c "filename"

[Tony Coor]

Output from ls shows as an example:
# ls -al ./kzfn5x/.jwin/iihs_side_defaults.txt
-rw-r----- 1 33140 1701 0 Aug 2 1940 ./kzfn5x/.jwin/iihs_side_defaults.txt
# ls -cl ./kzfn5x/.jwin/iihs_side_defaults.txt
-rw-r----- 1 33140 1701 0 Jul 24 2003 ./kzfn5x/.jwin/iihs_side_defaults.txt

# ls -ul ./kzfn5x/.jwin/iihs_side_defaults.txt
-rw-r----- 1 33140 1701 0 Nov 8 2032 ./kzfn5x/.jwin/iihs_side_defaults.txt

Files are accessed from various clients including Windows and are stored on a networked server, not the HP box. So files could be accessed via CIFS or NFS from a number of clients but so far the problem seems to occur with files that have recently been access by the HPUX system through its NFS mount of the networked server file system.

[Jeff Schussele]

Well, the times are set by the local system - not the clients - *unless* the clients are placing the files on the server. Then the server will inherit the timestamp from the client.
What OS is this networked server running?
$ to doughnuts it's probably M$ crap.
Take a look at the M$ tech support site & search for date issue or such - you'll find the bulletin/patch I'm referring to.
But there's no way the HP system is giving that timestamp to the server. At best it's being misinterpreted by it.

My $0.02,
Jeff

[Cheryl Griffin]

Could someone have rolled the date forward to do testing? Most recently, people were testing for a feared date issue that was to hit 01/10/2004 or 2^30 seconds. The next date issue may occur in 2038 where 32-bit applications may have a problem calculating the 2-billion-second mark or 2^31 seconds.

[Tony Coor]

Good suggestion on the Y2Kx testing, we did think of that and it turned out not to be the case. I think the M$ leads are going to be fruitful and I thank everyone for their postings and comments.

[Tony Coor]

Looks like it may be a NFSv3 problem in the HPUX client implementation. Looking at a network trace it appears that other Unix clients upon using an Open Exclusive would later setnd a SetAttr command specifying the atime value in the packet specifically. The HPUX sends its request specifying that the current date/time values should not be changed, i.e. it takes a default initialization of the packet. Others have had this problem and patched for it so that the value is set to specific client setting on the follow-up SetAttr call. I expect that HPUX will probably do this in a later patch to R11 as well. Thanks everyone for their helpful suggestions as they did provide a lot of assistance in ruling out possibilities.