Firebee/FireBee_Setup-Dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

initial commit

Browse Source
This commit is contained in:
root
2023-06-12 09:14:09 +02:00
commit b4912f303e
2545 changed files with 209350 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
mint/sys/share/doc/minix-tools/COPYING Normal file
View File

@@ -0,0 +1,39 @@
Minixfs is copyright S.N. Henson 1991,1992,1993,1994,1995.
This code may be freely distributed unmodified, provided this copyright notice
is intact. A small copying fee may be charged for redistribution provided this
does not exceed the equivalent of five pounds Sterling (UK currency).
You are free to compile, modify and recompile modified versions of this
program. Modified versions of this source may be redistributed provided:
1. Modified versions are clearly marked as such in each file modified.
2. This copying file is included unmodified in any distribution.
3. An additional startup message is added stating that it is a modified
version after the original startup message.
4. The orginal copyright startup message is not modified in any way.
5. No additional restrictions are placed on the modified version, in particular
full source must still be freely available and freely distributable.
Binaries compiled from this code may also be redistributed. Binaries
compiled from modified versions of this code may also be redistributed provided
this copying file is included intact and conditions 1 to 5 above are met.
This version may not be used for profit or in a commercial environment,
this includes the development of software that requires a registration fee.
If you wish to use Minixfs to develop anything other than free software or use
it in a commercial environment then Minixfs must be registered for a small fee,
please contact me for further details.
Distribution of this program with commercial packages is not allowed
without my written permission, please contact me if you wish to do this,
or indeed if you want a similar filesystem writing for a different purpose
(e.g. TT Unix or Spectre), however I am not in a position to write filesystems
for other commercial packages free of charge.
I reserve the right to modify these conditions at some future date.
Please note that although I believe each release to be stable and
test it thoroughly I offer no guarantee. Therefore, THIS PROGRAM COMES
WITH NO WARANTEE WHATSOEVER AND USE IS ENTIRELY AT YOUR OWN RISK, I WILL
NOT BE LIABLE FOR ANY DAMAGE CAUSED DIRECTLY OR INDIRECTLY FROM ITS USE.

13
mint/sys/share/doc/minix-tools/address.doc Normal file
View File

@@ -0,0 +1,13 @@
I can be contacted by email as shenson@nyx.cs.du.edu . Donations or snail
mail should be sent to:
S N Henson.
4 Monaco Place,
Westlands,
Newcastle,
Staffordshire.
ST5 2QT.
ENGLAND.
Phone: (within UK) (0782) 662808
(elsewhere) +44 782 662808

45
mint/sys/share/doc/minix-tools/bugs.doc Normal file
View File

@@ -0,0 +1,45 @@
No this isn't a list of bugs, its a list of what to do when you send a bug
report. I've included this because lots of bug reports I receive are incomplete
and I have to email back asking for more information, and often receive no
reply. It costs me real money to do this which is in very short supply.
Please use one of the following methods:
1. Technical description of bug, basically where it is in the source and/or a
fix.
2. As much information as possible about the bug. You should include:
a. Your hardware and hard disk driver software.
b. Version of MiNT, Minixfs and TOS.
c. As much information as you can about the bug. If I can't recreate the bug
then there isn't much I can do to fix it. Basically some method (as simple
as possible) to recreate the bug is best, also if fsck complains before
or after the problem as well. All relevant alerts or debugging/trace info
would help as well. Note also the output of minit with the '-t' flag should
be sent to me as well; this helps enormously in tracing bugs.
Please remember I have an STE and limited software, so if you say "When
I run x.prg on a minix partition it crashes" and 'x.prg' is commercial software
then I can't really do much to help. If 'x.prg' is free then I may be able to
download it. Alternatively if you know how to recompile minixfs and you don't
mind doing a few tests then I may be able to trace things that way. In any case
you should be prepared to answer a few questions at least.
One more point. Using Minixfs with older versions of MiNT may make bugs
appear which are caused by the MiNT kernel. Please use the latest version
possible. Preferably at least 1.08 . Any bug reports using MiNT versions prior
to 0.95 are untestable. The version of MiNT normally supplied with MultiTOS i.e.
1.04 can be rather unstable when used with Minixfs due to MiNT bugs (if you
try to change a disk with MiNT 1.04 is crashes horribly). A known MiNT 0.95 bug
is that it loads filesystems twice ...
Reports should be addressed to:
shenson@nyx.cs.du.edu
If you send it to Usenet then I may well miss it. In fact I may take a long
time to reply anyway, so mailing the MiNT mailing list may be more productive.

3
mint/sys/share/doc/minix-tools/flist.doc Normal file
View File

@@ -0,0 +1,3 @@
This is another quick hack program. Useage if flist X: . This will print out
all the inodes of open files on drive X: . You can then run fsck with the -i
option to find out what the files are.

150
mint/sys/share/doc/minix-tools/fsck.doc Normal file
View File

@@ -0,0 +1,150 @@
Fsck is a File System Consistency checKer. It checks Minixfs filesystems for
consistency and optionally repairs them too. It is important that a Minixfs
filesystem is checked for errors when, for example, the system crashes or a
lock up forces a reboot when programs are using the filesystems. This will
occasionally mean that fsck will perform minor repairs which will cause no
damage at all. Using a damaged filesystems can result in much more serious
damage occuring at a later date which require more destructive repairs to
fix.
ADVICE ON USE OF FSCK
fsck cannot perform miracles; a severely damaged filesystem (such as if a lot
of sectors get wiped somehow) may have very little salvageable. However, don't
be overwhelmed by the options available. In practice only fsck -n or fsck on
its own are used, the -p option is useful in shell scripts where non-interactive
repair is needed, but you dont want any attempted destructive repair.
If fsck -n does produce what appear like a lot of serious errors then it might
be an idea to attempt to backup the data before trying repairs; of course if
you have a full backup (you do make regular backups don't you?) available it
might be best to forget about repair altogether and just reinitialize the
filesystem (with minit) and restore from backup.
USING FSCK
Fsck can be used in interactive or non-interactive mode. In interactive mode
you are prompted before each fix. In non-interactive mode, repairs are carried
out automatically or not at all. The option '-y' carries out all repairs that
fsck would suggest, the '-p' (preen) option carries out all repairs if the
Minixfs filesystems is only slighlty damaged and can be repaired without
destroying data, the '-n' option only prints out the damage: it does not
repair anything. The '-y' option is not recommended, unless you are sure it
is what you want.
The options are followed by the drive letter of the partition you want to
check for example,
fsck -p D:
REPAIRS CARRIED OUT
In order to know precisely what repairs are carried out you must know a litle
about the internal structure of a Minixfs filesystem. Each filesystem is
divided into blocks or zones, these are always 1K in size.
Each directory/file/symbolic link has an inode associated with it. This is
a small part of a disk sector which carries all information about a file
except its name. It contains the file access modes (including what kind of
entity the inode refers to) as well as it's size and a list of sectors where
the file can be found. If this list is not large enough then an 'indirection
block' which is a disk block containing a list of further blocks belonging to
the file is used (and recorded in the inode). If this is not enough then a
'double indirection block' is used containing a list of further indirection
blocks. With this information, all the data in a file can be accessed.
A directory is basically identical to a file except it has a different mode
number. The 'data' in this file is a list of 'entries' (or links) each entry
contains a filename and an inode number where that name can be found. The root
directory is always contained in inode 1. A field in the inode called it's
'link count' gives a count of the number directory entries that refer to it.
Every directory has two filenames '.' which refers to itself and '..' which
refers to the parent directory. The only exception is the root directory where
'..' refers to itself as well.
Each used inode/block is referenced in a bitmap. If the filesystem crashes
before this can be written out to disk then it will be inaccurate. Fortunately
fsck can rebuild the bitmaps from the data contained in inodes. This is what
the prompts asking about bitmap repair mean. They are harmless and it is
strongly advised that any bitmap repairs suggested are made.
If you use the filesystem and some used blocks do not have their bits set in
the bitmap then other files can use them, overwriting the original data. These
are called 'multiply allocated blocks'. fsck will give a list of these blocks
and (optionally) allow you to decide which inode is the valid block. Usually
the valid data is contained in the file with the latest modify time: the '-y'
option removes all of the references. By finding the files the inodes
refer to (e.g. with the -i option) you can look to see which file
contains the valid data and then interactively remove the other references.
The other files where the references are removed then have 'holes' in them,
you may want to try to recover them or just delete them after 'fsck' has done
its work. This is why it is important that the bitmaps are accurate and should
be checked regularly.
This is the 'best case' scenario of multiply allocated blocks. If the block
overwritten belongs to a directory then much more trouble is caused. After
deleting the overwritten reference in a directory lots of inodes may no
longer be referenced in a directory, these are called 'orphaned' inodes (they
have no parent directory). fsck has no way of knowing their original names,
but the data is recoverable. fsck makes entries for these inodes in a
directory called lost+found . The name chosen is simply the inode number. You
can then analyse the files/directories in lost+found and delete, rename or move
them to where they were originally.
The worst case is if an indirection block is overwritten. This can cause lots
of spurious messages about bad zone numbers and other multiply allocated blocks.
fsck cannot currently help much under such circumstances: if a certain inode
contains lots of multiple block number or bad zone numbers then it's best to
delete all multiply allocated blocks in that inode; either with fsck or finding
the inode on the disk and deleting the associated file.
Here is a summary of the possible repairs fsck performs:
1. Scan all inodes, allow deletion of multiply allocated blocks, inodes with
bad modes, truncation of inodes which reference too many zones.
2. Scan all directories, check for valid names and the existance of '.' and
'..' entries and allow fixing.
3. Check filesystem conectivity (that each inode has a directory entry) and
allow repair of any problems and reconnection of orphaned inodes.
4. Check bitmaps and repair; check inode link counts and allow repair.
MISCELLANEOUS OPTIONS
If the root directory gets destroyed it must be handled separately because the
lost+found directory will be killed also. If this is the case then the '-R'
option will reform the root directory. Unfortunately the directory increment
is determined from the root directory, so you must manually tell fsck the
directory increment with the '-d' option followed by the increment. If you
get this wrong then a large number of errors about directory entries will
be erroneously reported.
If for some reason the root inode is no longer a directory Minixfs
may get confused and not recognise the filesystem anymore. By asking fsck to
continue it will still check the root inode as though it were a directory: if
it looks OK fsck allows you to make it a directory again. However you will
have to reboot before the filesystem will be recognised by Minixfs again.
The '-i' option followed by a comma separated list of numbers will
print out the pathnames of the corresponding inodes. E.g. fsck -i 1,2,3 D:
This will print out *all* the possible names so e.g. fsck -i 1 d: may
give something like:
\.
\..
\dir\..
\dir2\..
etc.
The '-z' option allows an inode to be zeroed if for example it is
severely trashed and fixing would do more harm than good (e.g. if an
indirection block has been overwritten). -z may be followed by a comma
separated list of inodes to zero. NB use this option with extreme caution,
the data the inode refers to will be effectively deleted (it will still be
on the disk but no longer accessible directly). Using this option will also
cause related "errors" to appear (though all can be fixed) such as inode
and bitmap errors and links a free inode.
The '-e' option tries to find out the filesystem size by reading
as far as it can through a partition: this is an experimental option and
isn't too useful at present.

107
mint/sys/share/doc/minix-tools/latest.doc Normal file
View File

@@ -0,0 +1,107 @@
This version is mainly a collection of patches for minixfs pl10. Details are
contained below. Many thanks to all concerned!
The only addition I have made is a -z option to fsck to clear troublesome
inodes. See fsck.doc for more details.
**************************************
initial revision
**************************************
makefile fixes
**************************************
increase cache sizes
**************************************
From: inf03@Uni-Trier.de (Sascha Blank)
Message-Id: <9409051059.AA07720@Uni-Trier.De>
Subject: Better personae management for MiNT 1.11beta
use effective instead of real uid for access checking
**************************************
From: Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>
Date: Mon, 17 Oct 94 10:46:00 +0100
Message-Id: <9410170946.AA02849@issan.informatik.uni-dortmund.de>
To: mint@atari.archive.umich.edu
Subject: MinixFS: directory creation und symlinks
There are two other places where MinixFS uses the ruid instead of the
euid, that is when it creates a directory or a symlink (although for
the latter it does not matter). Also, the size of a symlink node is
set to the length + 1, but Linux (and probably Minix too) expects it
to be the length without the terminating null. And neither Linux nor
Minix knows anything about drive specifiers, but MiNTlib always adds
U: to an absolute path, making it difficult to, for example, extract
the Linux root filesystem with its symlinks under MiNT. I have fixed
this by always stripping the U: prefix on symlink creation and adding
it back in readlink. This isn't fully backward compatible since
before an absolute link target without drive has been interpreted
relative to the current drive, but i don't thinks this is much of a
problem. Another difference is that the link size reported by
getxattr may be off by two, but MiNT always uses PATH_MAX when reading
a link. If this creates a problem then getxattr will have to check if
the symlink name starts with a slash and add two to the size in this
case.
**************************************
From: Ulrich Kuehn <kuehn@GOEDEL.UNI-MUENSTER.DE>
Message-Id: <9411021016.AA21609@math.uni-muenster.de>
Subject: Re: Sync() and shutdown() system call
config.h, filesys.h, minixfs.c:
use Sync() and Shutdown() system calls
**************************************
From: Juergen Lock <nox@jelal.north.de>
Subject: Re: MinixFS 0.60 PL10 Patch Collection
Message-Id: <9411122007.AA00358@jelal.north.de>
. fix bitmaps Kmalloc calculation for larger filesystems
. a hack for fsck to check for sparse directories
. clear bitmap dirty bits on `unmounts' (Dlock), you'll get warnings
about bitmaps not written out after fsck runs sometimes, don't ask
me why... as long as fsck found no errors you can ignore them
. make sure symlinks always go in the same cache too
**************************************
From: Ulrich Kuehn <kuehn@GOEDEL.UNI-MUENSTER.DE>
Message-Id: <9411180940.AA27680@math.uni-muenster.de>
Subject: Re: sync patch for minixfs pl 10
don't run the update daemon if SYSUPDATE def'd
**************************************
From: scott@telle.dmi.stevens-tech.edu (Scott Kolodzieski)
Message-Id: <9411250353.AA09142@telle.dmi.stevens-tech.edu>
Subject: minor diff for minixfs pl10
really don't run the update daemon if MiNT >= 1.12
**************************************
From: woodford@esca.com (Steven Woodford)
Message-Id: <9411290411.AA05910@flash.esca.com>
Subject: One more patch for MinixFs PL10
don't delete "." or ".." even if dir increment > 1
**************************************
From: Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>
Message-Id: <9412160954.AA28843@issan.informatik.uni-dortmund.de>
Subject: MinixFS: completed support for V2 filesystem
add support for v2 triple indirection blocks
------------------------------------------------------------------------------

18
mint/sys/share/doc/minix-tools/mfsconf.doc Normal file
View File

@@ -0,0 +1,18 @@
The utility mfsconf is a very simple utility to set the filename translation
modes for a given device, or to inquire what they are.
To determine the file translation modes for a given drive (X: say) type:
mfsconf X:
The output is self explanatory.
To set the modes the options -d -s -x or -c are used for directory search
execute or creation translation. The letter is followed by one of the
letters n, a, t or m for neither, all TOS or MiNT scopes respectively finally
the drive is specified.
E.g.
mfsconf -d n -s a X:
sets directory translation to none and search translation to all on drive X:
All other modes remain the same.

69
mint/sys/share/doc/minix-tools/mfsdoc.doc Normal file
View File

@@ -0,0 +1,69 @@
This file is designed as an introduction to minixfs. What it is, what it does
and why you might want to use it.
Minixfs is an alternative filesystem which runs under MiNT. It can
replace the standard TOS MS-DOS like filesystem which is standard on the ST.
So why would you want to replace the standard TOS filesystem? Here are some
of the arguments for and against minixfs:
For:
1. Filenames are no longer limited to 8 characters with an optional 3
character extension, the standard filesystem supports mixed case 14 character
filenames. Alternative filesystems support 30 or even 62 character filenames.
2. The filesystem is much more U*ix like, supporting the standard user/group
ids, 3 access times (well for the V2 filesystem anyway) and so on. If you're
used to Un*x like filesystems then this will certainly make you feel at home!
Symbolic and hard links are supported too as are sparse files and the root
directory can never fill up.
3. The filesystem is compatible with that used by Minix as might be guessed
from its name. If you use Minix then using minixfs under MiNT will allow the
minix partitions to be accessible under TOS, in fact they can be set up to
appear almost indistinguishable from TOS partitions.
4. Because it uses an indirection block Un*x like filesystem it tends to be
somewhat more robust than TOS filesystems.
5. Full source is available, as am I. You find a bug, tell me and I'll fix it.
6. It is possible to make *huge* partitions, theoretically the limit is 4096Gb
if your hardware and software can take it (and I don't know anything that
can!). This is achieved *without* increasing the sector size, unlike the
standard TOS filesystems.
7. It is quite a bit quicker than TOS filesystems. If you don't use
write-caching disk software then the speedup using turbo mode is considerable.
Even if you do use write-caching software (e.g. ICD) the speedup is still
useable.
Against:
1. Programs which depend upon the filesystem format (defraggers consistency
checkers etc) will not work. I have written a consistency checker for Minixfs
however, which is supplied. A port of the Linux defragger is also available.
2. Non MiNT aware programs will not be able to access longer filenames and
some non conforming MiNT aware programs wont either. You can still use the
translated TOS compatible names though.
3. Minixfs is not officially supported by Atari. At least they've never told
me if it is. This has several consequences and some of the more cynical may
consider this should be put in the 'for' group :-)
4. Huge partitions have a few caveats, mainly due to buggy driver software.
Although work arounds exist. Roughly speaking this works in spite of the
driver software rather than because of it :-)
In spite of the above 'againsts' I regard minixfs as a very powerful
and useful addition to the ST (then again I would wouldn't I?). For programmers
it is very useful indeed particularly if you are porting from Un*x, many of
the standard kludges to make filenames fit are no longer necessary nor are
some of the tricks to keep TOS happy (like not unlinking an open file).
If you haven't decided not to try Minixfs by now then you'll want to
know more information. If you're unsure you can always experiment with Minixfs
filesystems on floppy disks first before comitting your hard disk.
The remaining files in this directory give information about minixfs
itself and the various tools for creating and fixing minixfs partitions.

181
mint/sys/share/doc/minix-tools/minit.doc Normal file
View File

@@ -0,0 +1,181 @@
The program 'minit' creates minixfs filesystems. Then can be created on a
TOS formatted disk or a TOS filesystem, then can also be created to alter
the parameters of an already existing minixfs partition.
WARNING: USING MINIT TO CREATE FILESYSTEMS WILL IRRETRIEVABLY WIPE ALL DATA
ON THAT PARTITION. This includes using it to create a filesystem 'on top' of
an already existing one. Don't say I didn't warn you.
FILESYSTEM VERSIONS.
Before you decide to make a filesystem you must decide which kind of filesystem
you want to make. There are two kinds at present V1 and V2. These are
compatible with the equivalent Minix filesystems. V1 filesystems are the
standard Minix filesystems used with all versions of Minix, they do have a
number of shortcomings, there is only one kind of file access time and V1
filesystems can be at most 64Mb in size. V2 filesystems are newer and are
the same as the V2 filesystems used by Minix 1.6xx (and presumably higher).
They have three access times and can be any size (if you hard disk software
will support it). I would strongly advise the use of V2 filesystems.
If you supply the -V option to minit you will make a V2 filesystem,
otherwise it will be V1.
DIRECTORY INCREMENT
It doesn't quite end there though. There are a couple more parameters
you should know about. Under Minix itself you can have filenames of at most
14 characters in length. Minixfs uses this value by default. However there is
a parameter called 'directory increment' which allows you to use longer
filenames. This parameter must be a power of two between 1 and 8 (inclusive)
in other words it can be 1,2,4 or 8. The maximum filename size is given by
the formula maxlength= increment*16 - 2. Thus increments of 1,2,4,8 will
result in maximum filename lengths of 14,30,62 and 126 respectively. However
be advised that every filename whatever length occupies this space, so if you
set the increment to 8 then a filename of length 1 will still use up the same
space in a directory as a filename of length 126. Setting this too high will
slow down directory operations somewhat. 2 is a reasonable value for this
parameter. NB If you use Minix itself then only the default increment (1) is
accessible to Minix; other values will seriously confuse Minix, so if you want
partitions to be accessible to Minix use increment 1 (the default).
The -n option allows you to set the directory increment, follow it by
the increment you want. If this option is not present then a value of one is
assumed.
PROTECTION
A couple of options deal with 'protection'. This is a somewhat tricky
subject. Basically protection is a method I use to prevent TOS from writing
to a Minixfs partition when MiNT is not running, if TOS did then the partition
would be damaged (possibly irreparably). If you will always use MiNT and
Minixfs, or you are absolutely certain you will never write to a Minixfs
partition without MiNT/Minixfs running then feel free to use no protection at
all.
However this is rather unlikely so you usually will need some form of
protection. There are currently two methods. Null Disk and other partition ID.
A Null disk makes TOS think it's root directory is full so it
can't write to a filesystem because it can't create any files.
If Null disk doesn't work then you can try an alternate partition ID.
This only works if you have software with an XHDI version of 1.10 or higher,
if you use the '-t' option to minit you can find out your XHDI version (if any).
The partition ID is a three character identifier for the partition type. TOS
uses GEM and BGM for its filesystems; you can use other types to ensure TOS
will never access the partition and Minixfs can. There are quite a few problems
though. Not all hard disk software allows the partition ID to be edited. Also
Minixfs can only automatically access other partitions with XHDI compliant
software (see the information provided by the '-t' option).
If you have XHDI compliant software and you can edit the partition ID
then you can use the ID MIX for Minixfs (you can also use RAW, but I wouldn't
advise it). After altering the ID, reboot and use minit as normal and all should
be OK.
OTHER OPTIONS
Normally minit tries to find out the size of a partition by itself,
this can sometimes fail. If it does then you must enter the partition size
(in K) manually with the -b option.
Inodes are part of the filesystem. Every file/directory/symbolic link
on the filesystem uses precisely one inode. If you run out of inodes then you
can't create any more files/directories/symbolic links without first deleting
some already there. The default number of inodes is a third the partition size
in K. If you want to create more then use the '-i' option followed by the number
you want. You can have at most 65535 inodes on a filesystem. The default will
almost always suffice, but you can increase this if you will need more.
The -S option writes out part of the filesystem called the 'super
block' only. If you accidentally wipe out the start of a partition then this
option may allow some data to be salvaged. If the start of a partition is
wiped out then the partition may not be even recognised as minix, so the -S
option can help under these rare circumstances. Note: you must use exactly the
same pararmeters you used to create the fileystem in the first place.
The -t option is a test option. It does almost everything needed to
create a filesystem without writing anything. It also gives a status report
of any options (e.g. XHDI support) the driver software may have. Use of '-t'
is recommended before actually creating the partition; it wont harm anything.
HUGE PARTITIONS
A *huge* partition is a partition where the logical sector size is
bigger than 1K. In practice this means bigger than 64Mb (or 32Mb with some
partitioning software). Unlike TOS filesystems when you create a Minixfs
filesystem bigger than 64Mb the filesystem is still accessed in 1K blocks.
In this sense if you create a 1 byte file when the logical sector size is
e.g. 4K you use up 1K of the disk not the 8K (2 sectors) TOS filesystems
would use.
If the partition you are creating is huge then you may have some
problems. This is basically down to bugs and inconsistencies in driver
software. I've tried to work around these as much as possible, but I can't
guarantee anything. The rules are explained below, which should help if you
want to create such a partition and minit complains. Generally minit will
complain if it can't find a work around for your software.
If the drive letter is A-P (inclusive) you should always be OK. If
you are using software which conforms to XHDI then you should also have no
problems (and you might want to set the partition ID to MIX as well). If
neither is the case then you may need to either obtain XHDI compatible disk
software or repartition/reorder (set the ID's so the large partition is on
the first hard drive) to make the large partition drive A-P.
The A-P restriction may be fixed in future versions of Minixfs if there
is any demand (however it is rather tricky to do).
RECREATING A TOS PARTITION
If you decide you want to turn a Minixfs partition back into a normal
TOS partition then you can use the '-r' option. This will recreate a blank
TOS filesystem on the partition selected. Certain hard disk software may not
recognise the new filesystem, so always reboot after you use this option.
Note: This option only works at present if you created the filesystem with
a newer version of minit. If there is any demand I may add an option for it
to work if the filesystem is older, by 'improvising' a bit.
Some hard disk software (e.g. ICD) and disk tools have an option to
rebuild a single partition without disturbing the others. If you have such
sofware then please use as opposed to the '-r' option. Such software will
probably work under all circumstances (e.g. filesystems made with older minit
versions). The primary reason I added the '-r' option was to allow people
without partition rebuilding software to be saved the effort of reformatting
or repartitioning their hard disks to get a TOS filesystem back.
USING MINIT
After all the options must come a drive letter (either case) followed
by a colon. You will then be given a warning, if you type 'y' or 'Y' then the
process continues, otherwise it is aborted. If you are running Minixfs/MiNT
the partition should be instantly recognisable. To check try using 'mfsconf'
and you should get some status info about translation modes (see minixfs.doc).
If you get the message 'drive X: is not minix' then there may be a problem.
Try rebooting, if that doesn't work try recreating a TOS partition (there
should be an option in you hard disk driver sofware to do this) and using
minit without any protection options. If this still fails then your system
hard disk driver software currently cannot use Minixfs partitions. Send me
a report (see the file 'bugs.doc') and I'll see what I can do.
WARNING: you should not make the partition you boot from or the partition that
you load MiNT and minix.xfs a Minixfs partition. This is because TOS cannot boot
a Minixfs partition or run MiNT/minix.xfs from a Minixfs partition.
EXAMPLES
Create a minixfs filesystem on drive A:
minit A:
Create a V2 filesystem on E:
minit -V E:
Create a V2 filesystem with increment 2 and null disk protection on drive D:
minit -V -d 2 -P D:
Test the disk driver software used to access drive F:
minit -t F:

59
mint/sys/share/doc/minix-tools/minixfs.doc Normal file
View File

@@ -0,0 +1,59 @@
MINIX.XFS is the minix filesystem driver. To use it copy MINIX.XFS to
the root directory of whichever partition you start MiNT from. Reboot and
you should get the startup Minixfs message. Any Minixfs partitions should then
be immediately accessible.
If you don't use MultiTOS then you should also copy nohog.acc into your
root directory (or wherever you load accessories from).
There isn't a great deal more to say about it from a normal users point
of view. The only thing which can potentially cause trouble is filename
translation.
The system calls specific to Minixfs are described in syscall.doc.
These are only likely to interest programmers.
FILENAME TRANSLATION
Some programs cannot cope properly with mixed case filenames. In
general a program which is not MiNT aware (and some which are) will only
receive 13 chacacters of a filename. This is not the fault of Minixfs, in
pre-MiNT days there was simply no way to pass more characters to a program.
Some quite common (!) programs have problems, for example the desktop and
the standard file selector. As a result Minixfs has the option to translate
filenames to the standard TOS form, that is 8 characters with 3 character
extension and upper case (this will be referred to as 8+3 format).
Naturally this translation is not ideal and some conflicts may occur.
The normal translation rule is to make the filename upper case and to retain
the original extension. For example FooBARFilename.C becomes FOOBARFI.C. The
basename and extension are cut back to 8 and 3 characters respectively as
would be expected. Periods are replaced by commas in all but the extension.
There are four cases where translation can occur and 4 'scopes'. The
scope determines when a program should receive translation. The scopes are
all, MiNT domain, TOS domain and neither. Usually a program that understands
MiNT will run in MiNT domain; otherwise it will run in TOS domain. Clearly the
'neither' scope means translation will never occur for that case and 'all'
means it will always occur.
The 'cases' are search, directory, creation and executability.
When you attempt to access a file, 'search' is used. For example if the scope
means translations occurs for a specific program then if the file
FooBARFilename.C exists then it can be accessed as FOOBARFI.C. When a directory
is listed 'directory' translation is used, thus FooBARFilename.C will appear
as FOOBARFI.C on e.g. the desktop.
Creation is slightly different. This simply translates all filenames
created to lower case. So a TOS program creating FOOBARFI.C will actually
create foobarf.c . This can be useful for certain programs which translate
filenames to upper case.
Executability refers to creating files as well, if a file is created
with the extensions ttp,gtp,tos,prg (either or mixed case) then the 'x' bit
in the filename is set automatically. This makes sure executable programs
stay executable. This is useful for utilities that copy files but are not
aware of MiNT's extensions.
You can set the translation modes to different values for different
partitions, using the utility 'mfsconf'.

44
mint/sys/share/doc/minix-tools/readme.doc Normal file
View File

@@ -0,0 +1,44 @@
Welcome to Minixfs! If you are attemting to use Minixfs for the first time
then I would advise you read all the docs in this directory (except
syscall.doc). Otherwise you can just read latest.doc for features added to
the latest version and any bugfixes etc. (for more detailed info read the
'changes' file in the source distribution).
Here is a summary of the contents of the document files:
copying Conditions of use.
address.doc Contact addresses.
mfsdoc.doc introduction to Minixfs and why you may or may not want to
use it.
minit.doc How to use 'minit' to create a Minixfs partition.
minixfs.doc How to install Minixfs and about filename translation.
flist.doc Description of flist utility.
csize.doc Cache resizing utility.
fsck.doc How to use fsck to fix filesystems and a bit of backround
as to their structure.
mfsconf.doc How to use mfsconf to set the filesystem translation modes.
mount.doc How to use the mount program.
bugs.doc How to submit a bug report.
syscall.doc Minixfs specific system calls and special features of standard
system calls. Only really of interest to programmers.
latest.doc Bugfixes and/or features of this version.
NB Read the file bugs.doc before submitting a bug report. I don't have access
to your system so all I know about it is what you tell me, this file tells you
the kind of information I need to have a reasonable chance of fixing a problem.
I waste a great deal of time and money simply asking people to give me the
proper information after an initial report saying "Minixfs doesn't work" or
a nasty post to Usenet. In future I'll ingnore such reports, if you can't be
bothered to read the docs then I can't be bothered to help.

212
mint/sys/share/doc/minix-tools/syscall.doc Normal file
View File

@@ -0,0 +1,212 @@
This file describes some of the syscalls and some special aspects of the
standard syscalls.
STAT (Fxattr)
Almost all the fields are relevant and not 'faked' unlike most of the
standard filesystems. There are a couple of minor exceptions. For V1
filesystems atime/adate and ctime/cdate fields are faked, they are
the same as mtime/mdate; these are not faked for V2 filesystems. The
nblocks field is faked by just assuming the file is continuous, this
will usually be correct; if the file is sparse however this will be
too high.
The 'dev' field is the drive with the standard form 0=A,1=B etc. The
field 'index' is the inode number, this is again valid: if two files
or file descriptors have the same inode and device numbers then they
are the same file, otherwise they are different.
If there are character or block special files on the device then the
field 'rdev' gets filled in appropriately.
DOPENDIR (DREADIR)
In normal mode you never get translated filenames, in addition the
long field is the inode number.
RENAME
You can 'move' directories with this call, as would be expected for
a U*ix like filesystem. This naturally moves all the contents of that
subtree as well. This call will not allow a directory to be moved inside
itself, as this would damage the filesystem (and is illegal anyway).
FDATIME
This is made fairly close to 'utimes', basically setting both atime/mtime
to the value specified and ctime to the current time. It can't change the
times for directories because MiNT blocks opening directories.
FATTR
This is largely faked, the fields aren't really valid for U*ix like
filesystems. Only the DIR/RDONLY bits have any meaning, and RDONLY
can be set as well.
VOLUME NAMES
Basically these don't exist. I suppose I could add support in some way if
there was any demand.
LINK/SYMLINK
As would be expected these are perfectly valid. LINK does not allow hard links
to directories, even by superuser basically because there is no real need since
symbolic links can do this and there would be no way to remove them.
UNLINK
Unlink behaves in a U*ix like manner with regard to open files. Basically you
can unlink() an open file and let all processes with it open read/write as
normal. When all processes close() the file (or exit which closes anyway) the
space used by the file is freed up.
You can *not* unlink directories, this would be too risky and isn't needed
anyway.
FSEEK
Minixfs allows the creation of sparse files in the usual way (seek past EOF and
write).
DCNTL CALLS
The Dcntl syscall has several options for minixfs filesystems. The 'standard'
calls FUTIME (set inode times) and FTRUNCATE (truncate file) exist as do their
Fcntl (ioctl) equivalents. However also inluded are several Minixfs specific
calls.
Opcode 0x100 MFS_VALID
This interprets the value of the additional argument as a long pointer, and
is stores the value MFS_MAGIC there. This is intended so that the path passed
to Dcntl can verified as being on a minixfs filesystem. MFS_MAGIC has the
value 0x1870431. Because of the possibility of other filesystems using the
same numbers for Dcntl functions with different purposes (though none do as
far as I know) MFS_VALID should always be called before using the other Minixfs
specific opcodes and MFS_MAGIC checked.
Opcode 0x101 MFS_SYNC
Synchronise *all* filesystems, basically write out internal buffers to disk.
Currently the filesystem internally sync()'s as well at various points, so
this call is not at present necessary before rebooting the system.
Opcode 0x102 MFS_CINVALID
Invalidate all cache entries for a given drive. This is used mainly internally.
Opcode 0x103 MFS_FINVALID
Invalidate all file descriptors on the given drive.
Opcode 0x104 MFS_INFO
This call basically returns some info about the Minixfs filesystem on which
the path resides. It interprets the value of the additional parameter as a
pointer to an mfs_info structure. This structure has the following form:
long total_inodes,total_zones;
long free_inodes,free_zones;
short version;
short incr;
long res1,res2,res3,res4;
(long=32 bits, short=16bits).
total_inodes and total_zones return the total number of inodes and zones
for the filesystem. Similarly free_inodes and free_zones show how many are
unused. A 'zone' is always 1K. version is 1 for V1 filesystems and 2 for
V2. incr is the directory increment. You can use this to determine the
maximum filename size with the formula incr*16-2. The MiNT syscall Dconf
can also be used for this purpose (see MiNT docs).
Opcode 0x106 MFS_IMODE
The extra paramater is interpreted as a long int. Its value is used to set
the mode of *all* the bits of the file pathname points to. Including the
type fields, thus you can change directories to files, and vice-versa.
This is again root only. Extreme caution is needed with this syscall: it
can do a lot of damage.
Opcode 0x107 MFS_GTRANS
Opcode 0x108 MFS_STRANS
This call gets and sets the translation modes for this device. Only the
superuser can do this. The extra parameter is interpreted as a long
pointer. The scope corresponds to the following values.
#define NONE 0
#define TOS 1
#define MINT 2
#define ALL 3
The 'type' is contained in groups of two bits. Bits 0-1 correspond to
search translation, bits 2-3 are directory translation, bits 4-5 are for
creation translation and bits 6-7 are for execute translation. All other
bits are currently ignored and should be set to zero.
Opcode 0x10a MFS_IADDR
The argument is a long pointer which will have the start address of Minixfs
placed in it. If Minixfs has crashed then using this address along with the
symbol table (or a suitable debugger) allows the precise point of the crash
to be determined.
Opcode 0x10b MFS_UPDATE
This controls the update daemon. If no daemon is running (e.g. not Turbo mode)
then this function returns -1. Otherwise the argument is a long which is
interpreted as follows.
0x0: Return 1 if daemon suspended, 0 if running.
0x1: Suspend execution of the daemon.
0x2: Resume execution of daemon.
0x3: Return the process id (pid) of the daemon (returns -1 if daemon not used)
Opcode 0x10c MFS_MOUNT
This is a bit experimental at present. It is used to mount one Minixfs
filesystem on another and may go away some day if the kernel implements
this (which is where it should really be). 'arg' is a pointer to the
following structure:
unsigned int dev;
long flags;
long reserved[4];
dev is the device to mount (the path to Dcntl gives the path to mount on).
flags is unused at present and should be set to zero. The reserved fields
are also unused at present. The Dcntl path must be a directory other than
the root directory. The filesystem of device 'dev' must not have any filesytems
mounted on it already.
Opcode 0x10d MFS_UMOUNT
The filesystem the Dcntl path is on is umounted.
Opcode 0x10e MFS_LOPEN
arg points to the following structure:
long limit;
unsigned int ilist[SIZE];
The field 'limit' should be set to the value of SIZE (the size of the ilist
array). After this call the inode numbers of all open files on the Dcntl path
filesystem are entered into the ilist array, followed by a zero terminator.
If there isn't enough room in the array, it is truncated and ERANGE returned.
Opcode 0x10f MFS_MKNOD
arg is a long. The low word is a mode parameter which is the full mode of
a character or block special file mode. The high word is the major/minor
device numbers of the file. The Dcntl path is the path to create.
NOTE ON FILENAME TRANSLATION
Using minixfs filesystems you should always use the Dopendir etc. MiNT calls
in normal mode. This way you never get translated filenames. You can use the
Dconf or the MFS_INFO Dcntl syscalls to get the maximum filename length (if
needed).