TIP: Click on subject to list as thread! ANSI
echo: locuser
to: David Begley
from: Bob Lawrence
date: 1996-07-15 09:19:16
subject: Paul gets up to mischief.

BL> I said nothing about relevant information "gone forever."

 DB> Sure?

  Yes.

 DB> I was certain you told Paul to give up trying to restore his
 DB> dates and times because his stuffing around had consigned them
 DB> to the great bit bucket in the sky.

  I said nothing to Paul about his efforts except my snide remark
that he was very "courageous" knowing that most people here were
Yes Minister fans and would recognise it as a Sir Humphrey euphemism
for fuckwit.

 DB> No doubt Paul (archiver of the ages) has the necessary evidence
 DB> to implicate the true culprit. 

  Who gives a shit *what* Paul has archived? Give me a message and
with a bit of creative quoting I can make it say anything I like.

 BL> It uses two different tables, doesn't it, in different
 BL> locations?

 DB> *Very* simplistically, HPFS splits the disk into 8Mb "bands"
 DB> and places directory information for each band at alternating
 DB> start/end locations, something like this: [administrivia]
 DB> [dir1] [band1] [band2] [dir2] [dir3] [band3] [band4]

  Ahh... that makes more sense. Where does the partition information
go?

 DB> The FAT file system is an abomination - in theory, you can have
 DB> any number of positive integer FATs from one upwards .. but
 DB> most software is hard-coded for two, and expects them one after
 DB> the other. Of course, by the time one is corrupted the data is
 DB> copied straight over the second, corrupting it as well. 

  Yair... and then you stand to lose the *lot*. In my fun and games
with learning pointers I managed to corrupt FAT a few times, and it is
frigthening how fragile it is. When you check the file itself, it is
usually intact... it's just that the FAT has decided to make it a
different length which overflows and ruins a few other files in the
vicinity.

  I'm surprised that HPFS does the same sort of thing only on a
smaller scale. I would have thought it would be more sensible to have
a backup set of directories physically removed, thus:

  [dir1-1][band1][dir1-2] etc...  

 DB> The fact that Paul was able to recover so much is testimony to
 DB> just how reliable HPFS really is when it comes to the crunch.
 DB> With FAT, he would have had no chance. 

  Yair... I've never given it much thought. I seem to lose data two
ways:

1.  The FAT gets confused and a few files are corrupted with the wrong
lengths. I manage this by compressing the drive and working on the
end. That way only recent files are affected.

2.  The disc crashes and I lose boot information. In this case I am
totally stuffed. I manage this with a backup. 

Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---
* Origin: Precision Nonsense, Sydney (3:711/934.12)
SEEN-BY: 711/934 712/610
@PATH: 711/934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.