topic Re: file access time in the future in Operating System - HP-UX

file access time in the future

Tony Coor — Tue, 10 Feb 2004 07:28:39 GMT

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

Re: file access time in the future

Mark Grant — Tue, 10 Feb 2004 07:36:15 GMT

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.

Re: file access time in the future

Jeff Schussele — Tue, 10 Feb 2004 07:36:56 GMT

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

Re: file access time in the future

RAC_1 — Tue, 10 Feb 2004 07:40:03 GMT

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"

Re: file access time in the future

Tony Coor — Tue, 10 Feb 2004 07:46:27 GMT

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.

Re: file access time in the future

Jeff Schussele — Tue, 10 Feb 2004 08:03:25 GMT

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

Re: file access time in the future

Cheryl Griffin — Tue, 10 Feb 2004 08:31:04 GMT

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.

Re: file access time in the future

Tony Coor — Tue, 10 Feb 2004 09:25:26 GMT

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.

Re: file access time in the future

Tony Coor — Wed, 11 Feb 2004 09:30:28 GMT

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.