home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Datafile PD-CD 5
/
DATAFILE_PDCD5.iso
/
utilities
/
f
/
fsck
/
fsck_help
< prev
next >
Wrap
Text File
|
1996-12-22
|
23KB
|
508 lines
fsck (1.31) - map fixer and analyst
NOTE: this program is SHAREWARE. Read the !SHAREWARE file for more info.
fsck is a disc utility that fixes the map of an E-Format disc (hard or
floppy) if it is corrupted for some obscure reason. fsck can also report
some information about the way the files are allocated (such as the bytes
lost because of sector boundaries) and eventually print a detailed
description of the map and directories organization.
fsck can also be considered as a replacement of the *CheckMap command because
it is faster, less prone to crash and can give useful informations on the
files allocation.
Index
-----
- Usage
- What it does
- The logfile
- fsck and Risc PC
- fsck and 'big' discs
- Return values
- Notes
- Extra features
- Disclaimer
- Limitations
- Bugs
- Results achieved up to now
- History
- Credits
- Conditions of use
- Contacting the Author
Usage
-----
fsck [-options] [-d lostdir] [-l logfile] [pathname]
Most used options:
-s calculate statistics
-f try to fix map if broken
-l print the results in "logfile"
Less used options:
-h print help informations
-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)
-c produce output like *CheckMap
-m ask the user to eventually move files instead of changing map
-n don't try to recognise directories
The default directory where files are linked is "$.lost+found".
If 'pathname' is not specified, the current disc is analysed.
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'.
The -m and -n options used together cause fsck 1.20 or later to work like
fsck 1.13 or earlier.
What it does
------------
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.
If the file was originally a directory, fsck tries to relink it,
reconstructing the directory name and content. Even if you want to keep the
relinked files or directories, you should copy them and delete the original
one, because there is the risk that your map will be corrupted again,
especially if you try to change them.
Apart from directories and their content, the re-linked files are usually
longer than the original lost file because fsck always links whole sectors
(and there is no way to know the original length), their filenames are random
and filetypes are always &FFF (Text).
Using the -m option, fsck could tell you that an ID is regularly allocated
for another file and 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. Without this option, fsck will change the ID in the map and
rewrite it to disc. The -m option is in fact only useful if you prefer not to
modify your map: anyway, remember that moving files on a corrupted disc can
be quite dangerous and can eventually corrupt other parts of the disc.
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.
The logfile
-----------
Using the logfile (-l) option is generally really useful: if something
strange happens, the author will be more helpful if he can see exactly what
happened and you don't even have to try to explain what happened when you run
fsck, the logfile is usually enough!
The logfile contains exactly what it is printed to the screen: unless you use
the -v option it will be really small (nearly 2K on a good map or nearly 10K
on a quite corrupted one).
You cannot save the logfile to the disc being analysed.
If a file with the same name as the logfile already exists, the new data will
be attached at the end of it: in this way, you can attach together two or
more logfiles.
fsck and Risc PC
----------------
fsck and CheckMap are no more equivalent on Risc PCs! In fact, Acorn changed
some behaviour of the FileCore module in RISC OS 3.50 so that it can now cope
with over-allocated files (ie. files that have allocated more space than they
need). This sort of files on older versions of RISC OS causes CheckMap to say
"Map inconsistent" and if you try to delete such files you will lose some
space. On RISC OS 3.50 (or later) CheckMap no longer says "Map inconsistent"
if over-allocated files are the only map problem and deleting them no longer
causes lost space. Compliment Acorn!
fsck still reports map corruptions in this case (on every version of RISC OS)
since an over-allocated file can be considered a problem (think of a 100K
file that uses up 10Mb of disc space and you will understand what I mean!).
Anyway, on a Risc PC, using the -m option you are able to discover such
files and you can fix the disc (assuming that your map is corrupted only
because of over-allocated files) by just moving them.
Remember that using the -f option fsck can cure the disc without moving any
file on every version of RISC OS.
fsck and 'big' discs
--------------------
In RISC OS 3.60 Acorn included a new version of the FileCore module that
supports 'big' discs (ie discs larger than 512Mb).
The unregistered version of fsck (version 1.31 or later) is able to scan such
discs but only the registered version will eventually allow you to fix any
map corruption.
Return values
-------------
This paragraph will be interesting only for programmers who want to write a
program/frontend which has to interface with fsck.
fsck returns to RISC OS a value that is 0 only if fsck was able to scan the
disc and the map is good, otherwise it returns 1.
fsck also sets the numeric system variable fsck$ReturnCode to a value that
can be more helpful in determining why fsck failed, or 0 if the map was good.
The value is formed by the following bits:
enum {
return_MAPGOOD = 0x00000000, /* the map is good (!) */
return_MAP_BROKEN = 0x00000001, /* the map is broken, fsck -f should fix it */
return_MAP_FIXED = 0x00000002, /* the map was broken but has been fixed */
return_MAP_UNFIXABLE = 0x00000004, /* the map seems to be unfixable... */
return_ONLY_MOVE_FILES = 0x00000008, /* the map is corrupted but RISC OS 3.50 or later is able to fix it moving some file */
return_NEED_ELIMINATE = 0x00000010, /* need eliminate to fix the map */
return_NEED_HARDFIX = 0x00000020, /* need hardfix to fix the map */
return_NO_ACTION = 0x00000100, /* no useful action performed (eg. fsck -h) */
return_PARAM_ERROR = 0x00000200, /* bad input parameters */
return_WRONG_FS = 0x00000400, /* wrong file system name, disc name, number, etc. */
return_IO_ERROR = 0x00000800, /* error while reading/writing disc, directories, etc. */
return_MEMORY_FULL = 0x00001000 /* not enough free memory */
};
You can expect that every possible combination of these values is returned
(ie. &30 means that both 'eliminate' and 'hardfix' are needed) even if
generally only one error number is returned.
If you are writing a 'C' program that has to call fsck you can use something
like this:
if (system("fsck ...")==0) {
/* map good */
}
else {
/* some problem occurred (not necessairily map broken!) */
/* check fsck$ReturnCode for more informations */
}
If you don't want to (or can't) check the return status you can just check
the value of fsck$ReturnCode.
Notes
-----
fsck is 20-30% faster than CheckMap (actually, up to 50% faster on big and
full drives!). If you really like CheckMap's output instead of fsck's one,
you can use the -c option so that fsck will print the directory tree as it
proceeds with the scan. You can eventually include the following alias in
your boot sequence so