APDL Public Domain 1/APDL_PD1A.iso/discutils/_a_l/fsck/fsck_help

Text File | 1994-06-26 | 13.7 KB | 285 lines

fsck (1.13) - a disc utility from UNIX (!)

NOTE: this program is SHAREWARE. Read the !SHAREWARE file for more info.

fsck is a disc utility that tries to fix the map of an E-Format disc (hard
or floppy) if it is corrupted for some obscure reasons. fsck can also report
some informations about the way the files are allocated (such as the bytes
lost because of sectors boundaries) and eventually print a detailed
description of the map and directory organization.


Usage
-----

fsck [-options] [-d lostdir] [-l logfile] pathname
  -s   calculate statistics
  -f   try to fix map if broken
  -d   link broken part of map in directory "lostdir"
  -v   print files location (-vv print also files position in zones)
  -D   just display disc information recorded in the map header
  -q   don't display disc information (quiet mode)
  -l   print the results in "logfile"
  -I   force fsck to run even if ImageFSFix module is installed
  -a   automatically move files for a better fix and run fsck again

The default directory where files are linked is "$.lost+found".
If 'pathname' is not a root directory (eg. ADFS::0.$.Library), fsck checks
only that directory and so it cannot tell you if the map is good or broken.
This could be useful if you want to know the statistics of a single directory
instead of the whole disc. If the -f option is used, the disc is scanned from
the root directory, regardless of 'pathname'.


What it does (or tries to do...)
--------------------------------

fsck scans the directory tree and checks the map to see if every file
registered in the map actually exists in a directory. If not, it creates
that file in a directory so that you will be able to delete it in the
normal way. Even if you want to keep that file, you should copy it and
delete the original one, because there is the risk that your map will
be corrupted again if you try to change the re-linked files. Note that
the re-linked files are usually longer than the original lost file
because fsck always link whole sectors (and there is no way to know the
original length) and that the filenames are random and filetypes always
&FFF (Text).
If fsck tells you that an ID is regularly allocated for another file, you
have to delete it (moving the file to another directory isn't enough, you
have to copy it and delete the original) and run fsck again. At the end of
the scan, fsck will tell you again which files should be eventually deleted.
Sometimes the disc may be so corrupted that you will need to run fsck more
than once, the program itself will tell you if a re-run is needed. All these
operations can be automated using the -a option. Anyway, fsck cannot
automatically move directories, so you have to do it manually; furthermore,
if fsck has some problems moving a file, you will be informed to do it
manually.


Notes
-----

fsck is a bit slower than CheckMap (15% slower without calculating statistics
or circa 2 times slower with statistics). However you can generally use fsck
instead of CheckMap (with -af options) so that it will check and (eventually)
fix the map. This will also give you (always, even without -s) the "Free
space chunks statistics" (see below).
Remember that it is better if you close all the open files on the disc that
fsck is examining (ie. don't *spool on it!!). If you run fsck in a TaskWindow
remember to avoid any save of data on that disc while fsck is running because
this will have VERY VERY DANGEROUS consequences if you use the -f option!!!
fsck has some problems with the ImageFSFix module (that is usually loaded by
ArcFS or SparkFS). This module allows applications that are stored as image
files to appear and behave like common applications. Unfortunately it also
causes fsck to consider them as directories: usually this means that you will
have some warning messages about files with SIN=0 but this can prevent fsck
to properly fix the map. So, if the module is loaded, fsck will complain
about it and will not run unless the -I option is specified.
fsck has been tried on a RiscPC and it worked without problems (but the -f
option has not been tried because the map was not corrupted, yet!). This
means that (un)fortunately Acorn didn't change the file system SWIs on the
new machine... I hope they fixed the bug that caused the corruptions...
fsck will always (except with -q) show the "Free space chunks statistics":
if your disc has a lot of small free space fragments you should try to
*Compact it (even more than once if needed), because your disc is very likely
to become corrupted... (see the "Can a serious filing system corrupt discs?"
section to understand more on this).
Using the -a option without the -f option will cause fsck to move the needed
file but then fsck isn't run again (because it should be useless without -f).


Disclaimer
----------

fsck never tries to write directly in the map but simply creates files in
a directory. This means that if something goes wrong you will have a
directory that contains unreadable files and (in the worst case) undeletable,
but the map is not changed and the other files untouched. Anyway some
serious corruptions will follow when you will start to write to the corrupted
disc! I am sorry for you but I AM NOT RESPONSIBLE for any loss of data on
your discs, so use fsck at your own risk. I tested it on many floppies and
it worked fine, even if the disc was heavily damaged, and I finally used
it on my corrupted hard disc that has been fully cured!
Remember that unless you specify the -f option, fsck will not write to your
disc and you are encouraged to make a backup copy of your important data
before running fsck -f.


Limitations
-----------

Actually fsck can't fix broken directories (but see the elim_help file),
unmapped files (ie. files that are linked in some directories but are not
present in the map), map checksum errors, unchained free space, very small
wasted space in map and physically damaged discs (!).
If you encounter one of that problems, please contact me, I'll try to add
some new features. I can be more helpful if you mail me the fsck printout (ie.
use the "-l logfile" option, run it in a taskwindow, use the spool command or
the redirection: "fsck ... { > filename }" or "fsck ... > filename"). Remember
not to spool/redirect the output of fsck to the disc it is examining!!


Bugs
----

Sometimes if fsck is stopped using the escape key a strange disc error is
reported. This error isn't real but you are adviced to reset the computer
if this will happen to avoid some dangerous consequences. Anyway, this only
happened once, so don't worry about it!
It seems that sometimes fsck needs to be rerun even if it doesn't advice you
to do so... probably this bug has been cured now.


Can a serious filing system corrupt discs?
------------------------------------------

Yes, it can! UNIX has his own fsck command (but it is included in the
system!!!), no comment on MS-DOS please ;-), and RISC OS has his own
problems too! No system will be able to survive to an unexpected power-down
but RISC OS seems to corrupt discs quite regularly! :(
I think, but these are only my guesses, mind you, that there is a problem
in the FileCore module that prevents the auto-compaction of E-Format discs
to work properly. When the compaction fails there could be a system crash,
with the HD light turned on, and a map corruption. Probably the files are
moved in the map but not physically, or some sectors moved over a file that
has not yet moved!
This could be the cause of some strange corruption on my HD (one day a
sprite file was mixed with a text file!) and also of the inconsistency of
the map of a lot of different people (with different HD interfaces).
The fact that the auto-compaction works fine on floppies makes me think
that the problem lies in the multi-zone format of hard disc but I can't
be sure...
One of the things I have never understood is where the auto-compact takes
the memory to use for moving the file(s). It could be possible that the
corruptions take place when it run out of memory...
Recently I started to issue the *Compact command on my HD, because this
will lower the possibility of an auto-compaction. A quite full HD seems to
increase the chance of corruption, probably because if the free space is
limited an auto-compaction is likely to happen.
I'd like to know what you think on this subject, especially if you have
different opinions or if you know the FileCore module better than me
(maybe someone from Acorn?).


Results achieved up to now
--------------------------

If you run fsck on your corrupted HD, please let me know! If it wasn't able
to fix it, I'll try to modify it to cope with your problem. If you want to
stay anonymous tell me not to include your name (eventually send me an
anonymous mail!!!).

Positive results:
 1) some 800K ADFS floppy (used during development).
 2) 100Mb IDE (ICS interface) partitioned in 84Mb/16Mb (both partitions
    fixed). Owner: Sergio Monesi (ie. me!)
 3) 100Mb IDE (ICS interface). Owner: Cristian Ghezzi
 4) 314Mb SCSI (Serial Port Alpha SCSI interface). Owner: K. Bailey
 5) 60Mb IDE (A4 portable). Owner: G. Castagno
 6) 48Mb SCSI (Oak 16 Bit interface). Owner: A.M. Baardholt
 7) 40Mb ST506. Owner: A. Goodfellow
 8) 80Mb IDE (A5000). Owner: Julian Wright
 9) 240Mb SCSI (HCCS 8 bit interface) partitioned in 2*120Mb. Owner: Kai
    Schlichting.
10) 245Mb IDE (A5000). Owner: H. M.
11) 80Mb IDE (A5000). Owner: Mike Henry
12) 121Mb SCSI (Lingenuity SCSI interface). Owner: R. Z.
13) 100Mb SCSI (Oak interface). Owner: JP Hendrix

Probably many other discs have been fixed but their owner didn't contacted
me...

Negative results:
 1) Someone reported problems on his 170Mb HD but he hasn't yet mailed me
    any logfile: fsck recovered only part of the lost space but the map is
    still inconsistent. Anyway fsck didn't damaged his disc and was at least
    able to give him back more than 1Mb of lost space!


History
-------

1.00   First fully working version. Released only via e-mail.
1.01   Fixed a bug concerning filing system names. Added -D option. Now fsck
       generally need only one run to fix a heavily corrupted disc. Added
       eliminate program.
1.02   Changed again the method to check filing system names (Thanks to
       Keith Bailey). Added percentages in statistics. Checks boot block
       checksum and shows defect list.
1.03   Now it is possible to scan a single directory instead of the whole
       disc. You can specify 'relative' pathnames (eg. @.Examples) instead
       of full paths (Thanks to Julian Wright). At the end of the scan fsck
       will tell you which files should be eventually deleted. Added
       statistics about fragmented files and free blocks sizes. Changed the
       'F's and 'D's with a rotating wheel... Added -q and -l options.
1.04   Cured a serious bug that has always been present but never caused
       problems (until 1.03). Added ImageFSFix check and -I option. Now fsck
       understands RISCiX partitions.
1.10   RISCiX partitions are now fully supported (ie. mapped out). First
       version distributed as SHAREWARE.
1.11   Added -a option. The logfile is appended to the end of the file if it
       already exists and now it contains the creation date. Great speed
       increase (up to 2 times faster without -s and 5 times faster with
       -s!!!). Now fsck is just 25% slower than *CheckMap (or 2 times slower
       with -s)! Added the note about "Free space chunks statistics" (see
       the section Notes).
1.12   Another speed improvement (just 10%)! fsck isn't yet as fast as
       *CheckMap but I'm working on it ;-) Fixed a possible dangerous
       behaviour of -a option. Added a warning for HD boot blocks marked as
       defect. Slowed down the wheel. Added files MapExpl and StatsHelp.
1.13   Faster again (15% with -s, 3% without)!! Now statistics are just a bit
       slower than normal mode. Automatic creation of lostdir. More messages
       at the end of the process that can help to understand what happened
       (ie. the disc is fixed, fixable, unfixable, etc.) and more helpful
       error messages (no more "Can't find 'AD::0.$': incorrect FS") if the
       floppy drive is empty!


Thanks go to:
-------------

- Keith Bailey who discovered that the first 3 versions of fsck were
  completely useless on his SCSI!! The 4th version finally fixed his
  map problems (twice!). Thanks for the comment about the clock too! :-)
- Adam Goodfellow and Atle Mjelde Baardholt for the beta-testing.
- Hans Ole Rafaelsen who tried fsck on 1.6Mb floppies.
- Julian Wright for his beta-testing, suggestions, PRM docs and interest.
- Ernest Ong who suggested me to write a map-corruptor program to test fsck:
  'eliminate' is ready, now I am working on 'corrupter' ;-)
- Cristian Ghezzi who let me play with his RISCiX partitioned SCSI for a
  whole day to discover some stupid fsck bug.
- Andreas Schubert (Platon) who tried fsck on his RiscPC.
- Kai Schlichting who said that fsck was one of the most useful 'Unix ports'
  for RISC OS, a program that the Acorn world really needed. Kai has been
  the first who sent me 'something' to register!
- Mike Henry who has been the first who sent me some pounds to register
  (actually he sent me 10 pounds instead of the 5 I ask!).
- the person who spread on Internet a document describing the E-Format
  structure.
- Mohsen Alshayef for his !ArcTools, a very useful utility that allowed
  me to search in the ROM FileCore module for some code...


Conditions of use
-----------------

fsck can only be distributed with eliminate and it's companion files.
Read the !SHAREWARE file for the conditions of use and distribution of the
whole package.


I can be contacted at the following address:

Sergio Monesi
Via Trento e Trieste 30
20046 Biassono (MI)
Italy

E-mail address:
[e-mail]
If you don't receive a reply (or if the message is bounced) I can also be
contacted at:
[e-mail]
or:
[e-mail]