corrupted timestamp on ASU shared files

[Carl-Martell Sippel]

Hello,
I have a customer reporting a strange problem on ASU shares since about week (or 10 days). Whenever they look at a file on the share, it may be opening, renaming or just checking the properties tab, the modify timestamp of the file gets corrupted. Windows doesn't show any date at all and on the HPUX command line it is interpreted as 1/1/1970.

Of course, this is a 10.20 box running ASU, "double" out of support, so I hope to find some good hint here. I have seen a few threads about similar problems here, but unfortunately without a real solution.
And as the customer is still running production on this box "no longer supported" doesn't really help...

I am able to reproduce the results the customer is seeing to some extent. The main difference is that I have the effect only for files with extensions unknown to Windows, if it is something like "*.txt" file everything works o.k. for me.

What makes me even more concerned is that I see the same effect on all the ASU servers I tested. The fact I received only one call is so far is probably because the other ASU servers are (fortunately) not so heavily used anymore.

Any help, hint, idea is appreciated.

Regards,

Carl Martell

[Steve Steel]

Hi

Has the customer updated his PC virus scanner.

A few months ago I saw something about norton latest versions screwing up timestamps.


Steve Steel

[Helen French]

Since this is an old system running an old OS, I would be curious if you have the latest patches (on HP-UX side) and the latest service packs and windows updates (for Windows side) installed. I would make sure that they have installed atleast the old Y2K patches and updates! Is it the same for Windows shares? what version of ASU are you running?

[Carl-Martell Sippel]

Hi and thanks for the answers so far.
Some additional information to answer your questions.

1) Client systems
The customer is using NT4 and Win2k clients, with and without antivirus software (Norton AV 8.1), but seeing the same problem everywhere.
I tested it myself using WinXP without AV software and W2k (SP3) with Norton AV as well.

2) Server Side
K420 and K460, HPUX 10.20
K420: ASU B.03.04.05, Netbios B.03.03.02
K460: ASU B.03.04, Netbios B.03.05
Systems are "recent" (as of Feb 03) with Security and important bugfix patches. We didn't apply any "enhancement" patches on 10.20 this year, but for sure are o.k. y2k patches...

I also did some testing on a ASU server running version B.04.06.06 (Netbios B.04.05) getting corrupted timestamps asa well.

A colleague pointed me to a 2 year old ASU patch (PHNE_24271). But as the problem is new to us (and the ASU server in use all the time), I doubt that's the solution. But there is a little bit of hope at least :-)

I also did the same kind of file creation from my client (XP) PC to a Windows share and that works just fine (timestamps stay intact).

Regards,

Carl Martell

[Carl-Martell Sippel]

short update:

testing with a NT4 client I couldn't reproduce the problem (timestamps stayed intact)

that's contrary to what the customer experienced, but of course I only trust what I see myself :-)

this makes me more suspecting the client side had some changes, like e.g. applying Windows Service Pack or security patches

[Michael Steele_2]

ASU is all about the permissions database on the HP-UX server and keeping it small.

While I don't ever recall this issue I've included what I do recall, which are the trimming steps of the perms database.

acladm -C (* check for errors *)
acladm -E (* list redundent names and obsolete ACL's *)
acladm -P (* list non-existent ACL's *)
net perms revoke (* ??? *)
acladm -S (* combine duplicates *)
acladm -U (* remove unknow users *)

Finally, after all of this trimming of the permissions database has occurred, run this command:

blobadm -qA (* shrink perms database *)

[Carl-Martell Sippel]

Michael,
it was worth a try and something I didn't know, thanks. But didn't help as well :-(

However, things have changed a bit so far that the customer explained they have NO trouble with NT4 clients. What they mean by having the same problem with NT4 clients is that _after_ the file was touched by a W2k client, the timestamp is gone for NT as well...

As W2k never was a supported client for ASU, there is probably nothing I can do to change it. I installed the final ASU version (plus some patches) on a test server, but the W2k clients still break the modify date.

With this updated knowledge I strongly suspect some W2k security fixes applied recently being the "culprit".

The final solution here will be to migrate production to HPUX 11.11 and CIFS/9000.

But I am still accepting ideas for possible workarouns on the current setup :-)

Carl Martell

[Carl-Martell Sippel]

FYI, just in case anybody still cares about ASU problems... :-)

The issue could be tracked down to the Symantec Antivirus Client 8 installation at the customer side. As soon as the online monitoring scanning is stopped or the 7.x client is used instead, the timestamp corruption does go back to the level that I were able to reproduce in the first place. But that's something the customer can easily workaround until they finally migrate to Samba - they obviously didn't really suffer from the "smaller" problem before...

Carl Martell