summer of 69

[Nobody's Hero]

Okay, crazy morning. We use advanced server on an old Kbox to talk to the NT world. Works very well, very few problems. This morning a user call to inform me that the time stamps on her files (not all) is from 1969. This company wasn't created until the 90's. Anyone ever heard of this happening before. I am at a stand still. I am sure that the touch was not used.

[Paula J Frazer-Campbell]

Robert

If HP box time is ok then blame it / investigate the Wondoze machines.


Paula

[Jeff Schussele · Accepted solution]

Hi Robert,

If a system in the UNIX world has no way to properly time-stamp something, you'll get one of 2 dates - either:

12/31/69 OR 1/1/70.

This is due to the fact that the very first UNIX system was fired up on New Years Eve 1969.

I suspect that an application or a misbehaving NFS connection is causing this.
I've seen it from some flaky unzip utilities.

Rgds,
Jeff

[Pete Randall]

Robert,

Where do these files actually reside? On the HP box or on the Windoze side?

Pete

[Nobody's Hero]

Thanks Jeff, very interesting.

To answer Pete's question. They reside on the unix host, however I am not sure where they came from. Probably a windoze box.

[Sajid_1]

hi,
Did you check the servers date and time? If it changes then check system clock settings.

Did you check the ASU configuration ? Is is configured to sync with any other time servers? Check the 'net time' command:
# net help time

[Nobody's Hero]

System time is fine. I sync using NTP from an outside time source. All other files seem fine on the K.

[Pete Randall]

Robert,

You said "not all" files. Can you identify anything in common amongst those that are from the "Summer of Love" vs the ones that are "current"?

Pete

[Sajid_1]

hello,

You said it's syncing with an outside time source. Then check that configuration. Check in any other server which does the same sync. Check the 'ntpq' and 'ntpdate' commands.

HTH

[Jeff Schussele]

Hi (again) Robert,

I just remembered that sometime back (6-12 mos) M$ NT had a "feature" that was causing files to be timestamped with a date a decade or two in the future - 2018 or 2024 - something like that.
I think if UNIX gets handed a file stamped this way, you may get the "default" '69 date.
Check a couple of NT systems that share files w/the HP system for "oddball" dates like that & if seen I believe that M$ has a patch for this feature.

Rgds,
Jeff

[Wodisch_1]

Hi Robert,

since UN*X (all flavours of) counts the time in seconds since 1st jan 1970, and used to use a 32bit signed integer to store it, what has happened must be something like this:
somehow you've got a negative number or one bigger than 2^21 (which then would be treated as a negative one)...

Just my $0.02,
Wodisch

[Nobody's Hero]

Thanks everyone, I learned something here. You all are a lot of help and I appreciate it very much.

Looks like the problem may be this.

winnt client running real time norton atnti-virus protection.

user creates a spread sheet today.
the client sends a Trans2 FSCTL request with all the FF's in the seconds field that should contain the #seconds since Jan 1 1970. This being interpereted by the server as a -1, so the the date that gets set for this file is Jan 1 1970 -1, which ends up being Dec 31 1969(specifically, one second before midnight on that date. I've opened a case to try and track and capture the failure through debugging and network monitoring.

Thanks again, lots of help,

Bob

[Kelli Ward]

Hi,
This may not be applicable, but the only time something similiar happened to me, was during a power outage. A system had a dead battery and the RTC was reset (1970).
The only files affected, were the ones accessed before the date change was noticed.
Doesn't sound exactly like your situation, but might be food for thought. (I think the system was a 9000/782.)
Good luck,
Kel

[Carl-Martell Sippel]

Hello,

I know it's some time ago since this was posted here, but I hope someone may still receive email notification abut new messages :-)

I am struggling with a similar problem where all of a sudden since a week or so files on a 10.20 ASU share are shown with 1/1/70 timestamp after they were touched by a windows client (and in windows explorer it shows no timestamp at all).

So I wonder if there was a solution to the problem posted above and of course I hope that it will apply for me as well :-)

Thanks and best Regards,

Carl Martell

[Scott Mitchell]

I too started seeing this and could not figure it out until the hint above about Norton Anti-Virus. The problem starts once you have a Win2000 client PC that has Norton version 9 installed. I don't have a solution, and don't know if there really is one ( other than migrating to CIFS on the HPUX box), since it's the FSCTL request that causes the problem.

[Steven E. Protter]

If possible I'd try and resolve this by putting the NT box and the K box on the same ntp time source.

http://www.ntp.org/

The client refereneced here:
http://www.eecis.udel.edu/~mills/ntp/html/build/hints/winnt.html

Has worked for me on NT/2000/2000 Server and 2003 Server and XP Pro. Its very versatile.

If you pick a good time source you should be able to get valid time on all the servers. That should leave the Symmantic product no choice but to use real times.

Of course you have to open up port 123 on your firewall and my admins refused to do that. They provided me a barely compatible NT/2000 Server time source internally.

ntpq -p

On Unix.

Just wondering if things are messed up there.

I had some problems with Linux boxes because i pointed them at time servers that were not public. I'm surprised someone didn't get annoyed. ntpq -p showed valid information but the clocks didn't update.

SEP

[Richard Darling]

Robert,
I'd like to help, but my memories of the summer of 1969 are very foggy...

[Deoncia Grayson_1]

I just keeping thinking of the song... by Bryan Adams :-)

I know this wasn't helpful but I've been avoiding making a comment upon this all day....

[Nobody's Hero]

OK The author of this message has to reply.
In 69 I was 8. Been working in IT since 21.


Boring I know, well the ASU date problem went away. Due to the fact we now run samba on Linux RH9 on an Intel System. Thats right Intel. I hate the hardware. But I have to admit, its been running Samba and Mondo Rescue for over a year without a reboot. Is it the hardware or windoze? Well, RH runs fine on intel.

Never figured out how to correct the original ASU problem. I was beaten like a rented mule.

4 points to all........

Chow

[Nobody's Hero]

Also, just to tell you.

After working with HP a while, we figured out that the problem is probably due to the date format on the windoze side. When it crosses over to UX we handle date conversion differently. Ux chokes and defaults to the day unix started, one day before new YEARS,69. at lease this is what I was told.

[Yogeeraj_1]

hi,

i wonder what will happen if you zip the files on the NT, transfer the zip and unzip it on the UX...

quite strange!

regards
Yogeeraj

[Andrew Merritt_2]

One factor I don't see mentioned above is timezones.

A value of zero for a date is taken as 1/1/1970 on Unix machines, as stated by a couple of posters above. One difference between Unix and Windows is that Unix systems keep time according to GMT (aka UTC), and then use a variable to determine how to display that in local time.

So it may be that the value set is zero, meaning midnight, 1 Jan 1970, but because you are in the US, the value displayed is 7pm 31 December 1969 (assuming East Coast time).

I suspect that's more likely than getting a negative value passed for the time.

What actual dates were you seeing?

Andrew

[Pete Randall]

Robert,

Normally I'm not a fan of closing threads but, if ever there was a candidate, this thread would be it!


Pete