Jeff Dunlop wrote in a message to Mike Bilow:
 MB> I just realized something.  You're talking about running HPFS386 in a
 MB> totally unsupported configuration!  HPFS386 is a component of Warp
 MB> Server, which is still shipping on the 3.0 kernel.  If you run HPFS386
 MB> on the 4.0 kernel, you're on your own.
 JD> That's what I was saying all along: "HPFS386 with Warp 4.0
 JD> is bad news." I have since seen that LA is using chkdsk32
 JD> with Warp Server, and is having the same problems. The
 JD> specific error messages are just typical chkdsk messages:
 JD> invalid size, minor file system error, etc.
No, as I said, I realized what you were saying.  It was my error not to pick 
up on it sooner.
 MB> the incorrect DLL will be called by CHKDSK.
 JD> Interesting. Which DLLs are involved?
The actual DLL is determined using a naming convention defined by CHKDSK and 
documented in the IFS specification.  CHKDSK, as a front-end, interrogates 
the filesystem for its internal identifier, which is an ASCII string.  When 
CHKDSK gets the string back, it looks for a DLL with the name "Uxxxxxxx.DLL," 
where "xxxxxxx" is the identifier string.  These DLLs are required to export 
four services to be called by various front-ends:
   Resident Name Table
   Entry Index  Name
         0      UHPFS
         1      RECOVER
         2      FORMAT
         3      SYS
         4      CHKDSK
   Entry Table
   Ordinal Segment Offset Flag Attributes
         1     1    0640   03  EXPORT GLOBAL  (RECOVER)
         2     1    0294   03  EXPORT GLOBAL  (FORMAT)
         3     1    086A   03  EXPORT GLOBAL  (SYS)
         4     1    0000   03  EXPORT GLOBAL  (CHKDSK)
The FORMAT utility is also a front-end, and it takes the "/FS:xxxxxxx" switch 
that is used to select the DLL appropriate for the filesystem type.  In order 
to correctly format with HPFS386 instead of HPFS, the "/FS:HPFS386" switch 
must be used to select the virtual UHPFS386.DLL, and from then on everything 
should work consistently.
As you probably know, however, there really is no UHPFS386.DLL, and calls to 
it are intercepted by the HPFSvvv.386 driver loaded by HPFS386.IFS (where 
"vvv" is a version number such as "200").  Oddly, HPFSvvv.386 is an LE-format 
file, like a Windows VxD!  The reason for this convoluted procedure is to 
preserve the security of an HPFS386 volume protected by ACLs.  In effect, 
HPFS386.IFS is a kind of shim.
 
-- Mike
--- 
---------------