ljdickey@water.waterloo.edu (L.J.Dickey) (02/01/90)
In article <1990Jan31.032956.28008@gpu.utcs.utoronto.ca> romwa@gpu.utcs.utoronto.ca (Royal Ontario Museum) writes: >Sorry if this has come up before, but I am really in need of info >regarding a reliable way to verify the integrity of the FAT. >Hopefully, the program should also go ahead and fix lost clusters, >etc. as automatically as possible. There is something called FSCK that is available from panarthea. You can get an index for panarthea by sending mail to archive-server%panarthea.ebay@sun.com and include this line: index binaries To get the file I think you want include this line: binaries/volume3 fsck To get instructions, include this line: help -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@water.UWaterloo.ca ljdickey@water.BITNET ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey ljdickey@water.waterloo.edu
hcj@lzsc.ATT.COM (HC Johnson) (02/02/90)
In article <1990Jan31.032956.28008@gpu.utcs.utoronto.ca>, romwa@gpu.utcs.utoronto.ca (Royal Ontario Museum) writes: > Sorry if this has come up before, but I am really in need of info > regarding a reliable way to verify the integrity of the FAT. > Hopefully, the program should also go ahead and fix lost clusters, > etc. as automatically as possible. > fsck.prg was previously posted. It works well up the 16 meg partitions. Since TOS 1.4 supports up to 32 Meg partitions, I have modified fsck.prg. I will send it to anyone who writes. Howard C. Johnson ATT Bell Labs =====NEW address==== att!lzsc!hcj hcj@lzsc.att.com
ncastellano@eagle.wesleyan.edu (02/07/90)
In article <1255@lzsc.ATT.COM>, hcj@lzsc.ATT.COM (HC Johnson) writes: > In article <1990Jan31.032956.28008@gpu.utcs.utoronto.ca>, romwa@gpu.utcs.utoronto.ca (Royal Ontario Museum) writes: >> Sorry if this has come up before, but I am really in need of info >> regarding a reliable way to verify the integrity of the FAT. >> Hopefully, the program should also go ahead and fix lost clusters, >> etc. as automatically as possible. >> > fsck.prg was previously posted. It works well up the 16 meg partitions. > > Since TOS 1.4 supports up to 32 Meg partitions, I have modified fsck.prg. > I will send it to anyone who writes. > > Howard C. Johnson > ATT Bell Labs > =====NEW address==== > att!lzsc!hcj > hcj@lzsc.att.com I recently used this program to un-scramble a very scrambled partition on my Megafile 30. Only problem, was when I told it to reclaim unused clusters, it also reclaimed a cluster that was marked bad in my FAT. I had to restore it by hand using a sector editor (I happened to know what sector it was.) Are there any programs out there which don't have this "feature"? -- _=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_ Mathematics is the subject in which we never know what we are talking about, nor whether what we are saying is true. -Bertrand Russell _-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_ Nicholas Steven Castellano | Box 4127 Wesleyan Station | Disclaimer: I am ncastellano@eagle.wesleyan.edu | Middletown CT 06457 | irresponsible. _=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_=_-_
paulm@ccicpg.UUCP (tmp Paul Moreau usenet acct) (02/07/90)
In article <1255@lzsc.ATT.COM>, hcj@lzsc.ATT.COM (HC Johnson) writes: > In article <1990Jan31.032956.28008@gpu.utcs.utoronto.ca>, romwa@gpu.utcs.utoronto.ca (Royal Ontario Museum) writes: > > Sorry if this has come up before, but I am really in need of info > > regarding a reliable way to verify the integrity of the FAT. > > Hopefully, the program should also go ahead and fix lost clusters, > > etc. as automatically as possible. > > > fsck.prg was previously posted. It works well up the 16 meg partitions. > > Since TOS 1.4 supports up to 32 Meg partitions, I have modified fsck.prg. > I will send it to anyone who writes. > > Howard C. Johnson > ATT Bell Labs > =====NEW address==== > att!lzsc!hcj > hcj@lzsc.att.com Last night while attempting to extract files using unlzh12.prg the system sat for a while blinking the drive light then crashed with 2 bombs. After rebooting the system I attempted to extract the files again using unlzh11.prg. It then came up with an error saying that there was insufficient space on Drive E to extract the files! Using the desktop show info it said that drive E had around 4 megs used with 0 bytes free. My E partition is a 16 meg partition! I then used fsck which quickly exited saying that all was fine! Around 1 year ago I wrote a program called dskana which bypassed all DOS calls, read the boot and partition blocks and with a built in driver read the FATs , directories and checked the blocks used by each file to make sure that they didn't use any more or less sectors than they should and also check to make sure they didn't use any blocks previously used while building a memory image of the FAT while tracing. At the end it compared it's FAT with the one on the DISK and showed a whole Sh*t load of blocks that were marked in use but not assigned to any particular file! Fortunatly I had the partition backed up so I had to use a SUPRA utility to 'clear' the partition which also cleared the directories and FAT entries. Just deleting all the files still left all those entries in the FAT since they weren't assigned to any files for directories. My point is that FSCK didn't do the job for a standard 16 meg partition! Now I'm working on dskana to not only find errors but to correct them. I'll also make it more general purpose and if I get it working I'll post it to whomever may want it. --- .==========================================================. | ### ####### ### | N O R T H | /==============\ | | ### ### ### | A M E R I C A |< An STC Company >| | ### ####### ####### | (was CCI) | \==============/ | |----------------------------------------------------------| | UUCP: ...ccicpg!dl2!paulm | Paul L. Moreau | | or ...ccicpg!dl1!paulm | Diagnostics Software Eng. | | or ...ccicpg!paulm | Irvine, California | `=========================================================='