utime problem

[Max Hailperin]

I reported earlier that touch was making my files date back to Dec 31,
1969. At that time, I speculated that it was a -1 error value not
being caught. Not so. I did up a couple quick test programs and
found two things out:

1) The time value is actually 0 (the epoch), not -1 (just before).

2) The fault is actually in the utime syscall itself, not the touch
program. Utime when given a null pointer to a utimbuf should set
the file access and modification times to the current time --
instead it is setting the modification time to 0 and leaving the
access time unchanged.

This still leaves unexplained why this is happening on the machines I
configured and not on my colleague's more out-of-the-box 5.2 system.
What did I break that could possibly make utime misbehave in this way?
Thanks in advance for any insight. -max

[Paul Jackson]

In article <MAX.94Au...@andretti.gac.edu>, m...@gac.edu (Max Hailperin) writes:
|> I reported earlier that touch was making my files date back to Dec 31,

|> 1969. ... I did up a couple quick test programs and
|> found two things out:
|>

|> 2) The fault is actually in the utime syscall itself, not the touch

|> program. Utime when given a null pointer to a utimbuf ...
|> is setting the modification time to 0 ...

What does an incorrect invocation of utime(2) have to do with
this? Are you claiming that "touch" command calls utime(2)
with a (nil) utimebuf pointer -- I doubt that it is.

Have you verified that the system where touch is setting
dates to 1969 has its clock set correctly?

--

I won't rest till it's the best ...
Software Production Engineer
Paul Jackson (p...@sgi.com), x1373