david, at 21:02 on May 21 1996, you wrote to Bill Grimsley...

BG> Dunno, I ran it once, just after an HPFS defrag, and it actually found
BG> and recovered a couple of files which I'd intentionally deleted ages
BG> ago.  At the time, I was rather impressed...

db> HPFS was designed from the ground up to be robust - despite what problems 
db> people may have, it's a pretty damn clever piece of work. 

And it's been around long enough to have most of its bugs ironed out by now
anyway (which is presumably why I've never had a single problem with it).

db> Throughout OS/2 2.1 and 3.0, I've had system crashes (hardware reset style) 
db> that have never lost a thing on any HPFS partition. 

Same here.  If the auto chkdsk finds problems here, it has always been able
to fix them on its own, and I've lost nothing either.  Not once.

db> Apart from the inconvenience of not being able to easily access 'em from 
db> DOS boot floppies, I'm now pretty damn comfortable with the HPFS file 
db> system.

I have this German ute called HPFS4DOS, and when run from the DOS CLI
(there's a Windows version too, but I've never tried it), it allows FULL
read and write access to ALL HPFS drives and partitions.  I've even run DOS
apps from HPFS drives under native DOS, yet have not had any problems with
it.  The entire archive is under 40Kb, so if you want a copy, let me know.

db> Boot from disks and take a look at the partition .. ooohh, yuk!  What a 
db> *mess* that ray-tracer made of my file system!  To start with, the entire 
db> ray-tracer's directory had replaced the contents of my
"\OS2" directory 
db> (dunno how the heck I was going to go with a ray-tracer as my operating 
db> system..), and it just went downhill from there...

Any idea what caused that?  OS/2, HPFS, or the app itself?

BG> ...but didn't know it could be harmful as well.

db> As Doug said - in rare cases (hasn't bit me yet, but I'm in no rush to 
db> experience, either!).

Good point.  In that case, no more /f:3 here until I actually need it. :)

db> I head a radio advert this morning - something along the lines of:

db> "Windows 95 calling Houston.  Errm, Houston - we have a problem;
db> business just isn't interested."

db> "Hang tight, Windows 95 - NT 4.0 is on it's way."

db> Will they ever learn?

Obviously not a M$ commercial then.  Whose was it?

BG> Which is why the Gammatech Utes work so well, presumably.  It does take
BG> quite a while when defragging to just one extent though.  :)

db> I figured that it just isn't worth defragging to one extent anymore;  

Agreed.  I tried it once, then decided on 2 (the GTU default is 3).

db> apparently, up to "n" extents are still stored in the
fnode(?) of the 
db> file's directory entry, and therefore occpy no more disk space - but after 
db> that, they start using a modified B+Tree or something to manage all the 
db> extents.

Interesting.

db> I don't recall just what "n" is, but the default for most
HPFS defraggers 
db> (3) is within that limit.

Which is presumably why that's generally their default.

BG> Incidentally, I was under the impression that MS's NTFS was very similar
BG> to HPFS.  Comments?

db> I haven't spent much time on NTFS, but from what I can gather, they took 
db> HPFS and added ACLs (a la HPFS386) and a journal system (a la IBM's JFS 
db> under AIX).

Understood.

db> Don't run Windows NT, don't care.  ;-)  (Although there's been a hint at 
db> work that I may have to admin one or more NT boxes starting within the next 
db> 12 months - we'll see.)

Oh dear, time to start sending out resumes, perhaps?  :)

Regards, Bill

--- Msgedsq/2 3.20