[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::pwv50ift

Title:Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server
Notice:Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server
Moderator:CPEEDY::KENNEDY
Created:Fri Dec 18 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4319
Total number of notes:18478

4307.0. "FAT problems in 5.0E" by UTRTSC::HARLE () Thu May 29 1997 10:41

It looks like our "old" V5.0C FAT security.lmx
problems are back again in V5.0E-eco0. I had the
impression they were gone forever since V5.0D-eco3.

A customer with V5.0E-eco0 has the following errors
in the lmsrv-logfile:

----------------------------------
FATInitializeSecurityDatabase: FAT CRC check failure,
rebuild in progress

ACL does not contain ID block, offset .......

FATSecurityTraverseIndex: Invalid entry offset ....
-----------------------------------

Of course this coincides with the lmsrv-process 
using up 100% CPU; after deleting SECURITY.LMX things
return to normal again, at least for a while.

Perhaps, the V5.0D-eco3 FAT patches were not included
in V5.0E-eco0 ?

Rein Harle
Digital Pathworks Support
T.RTitleUserPersonal
Name		DateLines
4307.1Confirmed. IPMT# HPAQ606NVVMSNET::P_NUNEZWed Jun 04 1997 16:0713
    FWIW,  I've worked with a customer with the very same problem today. 
    
    VAX 6320/VMS 5.5-2/PATHWORKS v5.0E
    
    FAT Volume was 768MB containing MS Office97 and Corel WordPerfect
    application suites.
    
    LMSRV went compute bound and lots of FAT related errors in PWRK$LMSRV
    log (including those in .0) and the event log ($ admin/analyze).
    
    Case# is HPAQ606NV
    
    Paul
4307.2Need more info.CPEEDY::FLEURYThu Jun 05 1997 09:1210
    RE: .-1
    
    Paul,
    
    If the FAT volume itself was created prior to V50E, please recreate the
    volume and move the files to the newly created FAT volume.  There was
    an error in the creation tables which would not create the FAT blocks
    correctly.
    
    Dan
4307.3VMSNET::P_NUNEZThu Jun 05 1997 10:5213
    
    Hi Dan,
    
    Well, in fact it does appear that the FAT volume was created about
    1.5 hours before upgrading to v5.0E.  This is based on comparison of:
    
    Create date of fat container file vs.
    Modified date of sys$system:pwrk$*.exe   
    
    But can you comment on the scope of this issue?  Are you saying ANY FAT
    volume created prior to v5.0E must be recreated to avoid this problem?
    
    Paul
4307.4CPEEDY::FLEURYThu Jun 05 1997 11:5911
    re: .3
    
    Sorry, I should have provided more details...
    
    There was a problem prior to V50E where FAT volumed 512Mb and greater
    had the cluster size incorrect.  The problem would be seen as the
    consumption of more blocks than expected.  Deleting files would only
    return some of the space.  It is possible that the CPU loop is trying
    to allocate space (which it thinks exists) which in fact does not...
    
    DAn
4307.5VMSNET::P_NUNEZThu Jun 05 1997 14:147
    Dan,
    
    Are you working my IPMT?  Will I be getting an IPMT update stating the
    solution is to recreate the fat volume (and the customer can safely
    assume this problem will not reappear)?
    
    Paul