Jeff Dunlop wrote in a message to Mike Bilow:
 MB> There were some problems in the early release that should be fixed by
 MB> the FixPacks, currently at XR_M005.  However, those problems should not
 MB> result in data corruption of the kind being reported by LA.  What are
 MB> you seeing?
 JD> With every uhpfs.dll newer than 4.0 GA, chkdsk reports what
 JD> appear to be spurious errors on all HPFS partitions. If you
 JD> do nothing but replace the DLL with the older version, the
 JD> errors disappear. This sounds identical to what LA has
 JD> observed on his system. He boots from diskette to correct,
 JD> which backgrades his uhpfs.dll, which allows chkdsk to work
 JD> correctly.
What are the exact spurious error messages?
 JD> If you allow the chkdsk to make corrections under the
 JD> post-GA DLL, you can kiss your data goodbye. The kicker is
 JD> that you may not know anything's wrong until you lose power
 JD> and have an automatic chkdsk wipe you out.
 JD> I've meticulously documented the problem. It's independent
 JD> of drive -- both SCSI and IDE have the problem, and
 JD> completely dependent on uhpfs.dll version. It's possible
 JD> that chkdsk and not uhpfs.dll is broken, but from my point
 JD> of view that's irrelevent.
Actually, there is essentially no CHDKSK apart from UHPFS.DLL.  CHKDSK is 
really just a front-end which calls the appropriate maintenance DLL for the 
particular filesystem (except for FAT, where CHKDSK does the real work).  
CHKDSK does this by getting the filesystem type from the appropriate system 
call, and then looking for a DLL file named "Uxxxxxxx.DLL" where "xxxxxxx" is 
the string returned for the filesystem type.
 JD> If you must run HPFS386 under Warp 4.0, you have to remember
 JD> to downgrade uhpfs.dll every time you run a fixpak. The
 JD> problems I've documented, the sheer unsupported nature of
 JD> HPFS386 in this configuration and the marginal benefits of a
 JD> +2MB cache on a single-user machine make HPFS386 far too
 JD> risky to stomach on a production workstation.
I just realized something.  You're talking about running HPFS386 in a totally 
unsupported configuration!  HPFS386 is a component of Warp Server, which is 
still shipping on the 3.0 kernel.  If you run HPFS386 on the 4.0 kernel, 
you're on your own.
There are several important advantages of HPFS386 over HPFS in a server 
configuration.  First, HPFS386 supports access control lists, which improves 
system security.  At a low level, access control lists are stored on the 
media in roughly the same way as extended attributes, so regular HPFS should 
leave them alone -- although it is not supported to run regular HPFS CHKDSK 
on HPFS386 in any case.  Second, HPFS386 has the potential to be much faster 
than regular HPFS when heavily loaded, because it runs more of the disk 
processing at Ring 0 and using the Strategy2 multiple request kernel 
interface.
I think, judging from what you are describing, that you are talking about the 
case where a partition is formatted under regular HPFS and then the drivers 
are switched over by hand to run HPFS386.  In this situation, the filesystem 
type returned by the operating system will be wrong, and the incorrect DLL 
will be called by CHKDSK.  This should not occur if the partition is 
correctly formatted by Warp Server with HPFS386 correctly installed.
I certainly do not recommend running HPFS386 "unofficially" in this way.
 
-- Mike
--- 
---------------