home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Format 67
/
af067sub.adf
/
ReOrg
/
ReOrg.doc
< prev
next >
Wrap
Text File
|
1992-10-04
|
45KB
|
1,111 lines
ReOrg V2.33
Shareware disk optimizer
English documentation
(C) 1992 Holger Kruse
Contents
--------
1. Conditions, Disclaimer
2. What is ReOrg ? - Short introduction
3. Hardware, Software needed; Installation
4. Usage
5. Error messages
6. Technical details
7. Option file format
8. Program version, update info
9. Acknowledgements
1. Conditions, Disclaimer
-------------------------
ReOrg is shareware. The program may be freely distributed
and copied, as long as the following conditions are
fulfilled:
- The sales price must not be higher than the cost of
an (empty) disk plus a nominal copying fee plus
costs for shipping. The total price must not be higher
than 6 US$ or 10 DM.
- All parts of the program and the documentation must
be complete. The distribution of single parts is not
allowed.
- ReOrg or parts of it must not be sold in combination with
or as part of commercial software.
- Program and documentation must not be changed in any way.
Exception (this means: acceptable is:) the use of
archivers such as LHArc and packers like "Imploder" or
"Powerpacker", as long as it is possible to retrieve
the original program/data.
I want to ask everybody, who uses ReOrg (except for one
or two test runs), to send the amount of
10 US$ or 15 DM
to the following address:
Holger Kruse
Ulzburger Str. 387-389
2000 Norderstedt
Germany
or to my new address in the USA:
Holger Kruse
12006 Coed Drive
Orlando, FL 32826
USA
Phone: (407) 381-3233
Please send only cash, eurocheques, American checks or
postal money orders (US$ only !). Do not send
stamps, disks etc. If you write to my address in Germany, please
allow some time until your mail is answered, because mails send
there are forwarded to my address in the USA.
Thank you very much in advance !
I will try and inform everybody, who as registered with
me as described above, when a new version of ReOrg
becomes available.
I have a new internet address: kruse@eola.cs.ucf.edu
But please note that this address may not be valid at all
times ! If E-Mail bounces, please try again after a couple
of weeks or try sack mail.
I explicitly do not guarantee for the correct functioning
of ReOrg. When you optimize disks, you always run the
risk of a data loss, of a change of your data or of
the destruction of your data. I explicitly reject any
responsibility for these or any other consequences from
the use of ReOrg whatsoever. This includes, but is not
limited to, secondary consequences, personal injuries or
other kinds on side effects.
I hereby explicitly warn each user:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! Optimizing a disk is always risky. !!!
!!! I strongly recommend each user to backup !!!
!!! or copy his disk completely before !!!
!!! optimizing it. It is the user's !!!
!!! responsibility to check his data for !!!
!!! completeness and correctness after !!!
!!! optimizing it. I explicitly reject any !!!
!!! responsibility for damages or changes. !!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2. What is ReOrg ? - Short introduction
---------------------------------------
ReOrg is a disk optimizer, i.e. a program that
improves the physical data layout on a floppy
disk or harddisk, in order to speed up file
and directory accesses.
ReOrg removes some problems that are caused
by AmigaDOS:
- file fragmentation:
When new files are created, it is possible that
AmigaDOS can not store the file contents in one
single consecutive block, because there is no
such block available on the disk. In this case
AmigaDOS sometimes scatters the file contents over
the whole disk.
ReOrg removes this problem by placing the contents
of each file in a single consecutive block.
- directory fragmentation:
In contrary to other operating systems (e.g. MSDOS),
AmigaDOS does not store directory data in a single
consecutive block. This leads to weak performance
for directory listings.
ReOrg tries to store directory data as closely together
as possible. This considerably speeds up commands like
"dir" and "lists" and the directory display within
file requesters.
- differences in disk format:
When you use disks under Kick1.2/1.3, which have been
formatted under Kick2.04, directory accesses are often
even much slower than usual. The reason for this is, that
placement of "FileList"-blocks has been changed from
Kick1.2/1.3 to Kick2.04.
ReOrg has an option where to place "FileList"-blocks.
This means you can optimize Kick2.04-disks for use
with Kick1.2/1.3.
ReOrg can be used with the following disk formats:
- all currently available AmigaDOS filesystems, including
- OldFileSystem (OFS: "DOS\0")
- FastFileSystem (FFS: "DOS\1")
- new (Kick2.0)-FileSystem (includes OFS and FFS)
- International FileSystem (has been in ROM at least
since Kick2.04 and will (possibly ?) be supported
from the Shell in WB2.1: "DOS\2", "DOS\3")
- All floppy disk and hard disk sizes are supported.
However, to optimizer large hard disk partitions,
you need a lot of memory.
- ReOrg recognizes FileSystems, which support different
disk capacities (e.g. High-Density-Drives for
1.76 MB capacity, that are built in some new A3000s).
- ReOrg supports "hard links" and "soft links";
however, "soft links" are not wholely supported by
Commodore yet. Therefore, ReOrg only supports the
(possibly preliminary) "soft link" implementation
of Kick2.04. I can not guarantee that this version
of ReOrg correctly handles "soft link" implementation
of future AmigaDOS versions.
- CAUTION: DYNAMIC Ram disks, like "VD0:" ((C) ASDG)
must NOT be optimized by ReOrg. Optimizing such disks
may lead to data loss !
- Of course, ReOrg can not optimize "RAM:". Anyway,
this would not make much sense.
- You CAN use ReOrg to optimize your resident,
non-dynamical RAM-Disk "RAD:" ((C) by Commodore).
- ReOrg has a one-disk-mode (optimize a single disk)
and a two-disk-mode (optimize one disk while copying
it to a different disk)
In comparison to other disk optimizers available on
the Amiga market, ReOrg is quite fast.
Optimizing a 880 kB disk on a standard 68000 Amiga
with 1 MB of free memory usually takes about 1:30
to 1:40 minutes. On a 68030 Amiga it takes only
1:20 to 1:30 minutes.
Optimizing a 40 MB harddisk on a 68000 Amiga usually
takes around 10 to 15 minutes, but this time depends very
much on the amount of free memory, type of controller
type of processor and the degree of disk fragmentation.
If you use a 68030 Amiga and have enough memory
available, the optimization time can be reduced to
about 4 minutes.
3. Hardware, software needed; Installation
------------------------------------------
To use ReOrg, you need an Amiga, Kickstart 2.04
or above and enough memory.
There is also a different version of ReOrg (V1.1)
available that also works under Kickstart 1.2/1.3
The amount of memory you need is approximately:
220 kB (needed for the program itself)
+ 7 kB for each MB of disk size
+ 5 * tracksize of your disk
+ 150 kB which are usually not used by ReOrg, but must be
left to avoid low-memory situations. (For large
partition sizes and much memory available, this
number may become higher)
Examples:
1) 880 kB floppy disk: 40 MB harddisk:
(11 sectors/track) (32 sectors/track)
220 kB 220 kB
+ 6 kB (7 kB * 880/1024) + 280 kB (7 kB * 40)
+ 28 kB (11/2 kB * 5) + 80 kB (32/2 kb * 5)
+ 150 kB + 150 kB
--------- ---------
404 kB 690 kB
200 MB hard disk:
(32 sectors/track)
220 kB
+ 1400 kB (7 kB * 200)
+ 80 kB (32/2 kB * 5)
+ 150 kB
---------
1850 kB
These numbers are only rough approximations to give
you an idea how much memory you need.
Actually for large partition sizes, ReOrg allocates
most of your memory as a cache.
This cache is the main reason why ReOrg is so fast.
For optimum speeds, the cache should have at least
2 percent of the size of your partition.
There is no installation required for ReOrg. In addition
to the program file "ReOrg", you do not need any
libraries, fonts etc.
However if you want to use the built-in help mode of ReOrg
the file "ReOrg.help" must be copied to the same directory
as the program file "ReOrg".
4. Usage
--------
ReOrg can be started from Shell of Workbench.
You can specify the following arguments / tool types:
FROM=device name source device name
TO=device name destination device name
PUBSCREEN=screen name name of the public screen
you want ReOrg to open on
(works since ReOrg V2.3)
SCREENMODE=typecode This option tells ReOrg to open
e.g. =NTSC:HiRes an own (custom) screen. As <typecode>
or =0x19000 you can specify the name of an
Amiga display-mode (like in Prefs/
ScreenMode), e.g. "NTSC:HiRes".
However I recommend you specify the
hex code (e.g. "0x19000" for
NTSC:HiRes), because the hex code
is not changed for different
languages (WB2.1 ?). Valid code are e.g.:
0x08000: HiRes
0x19000: NTSC:HiRes
0x29000: PAL:HiRes
0x39024: Productivity
0x41000: A2024 10Hz
A complete list is located in
the include file "graphics/displayinfo.h".
OPTFILE=option file name name of a user-supplied
option file (the format of this
file is described below)
SETTINGS=settings name of a settings file, that ReOrg
file name has previously saved (default =
"ReOrg.prefs")
From Workbench ReOrg can also be started by double-clicking
on an settings file.
When you start ReOrg, the main window appears. ReOrg is
controlled by menus and gadgets.
Description of menus:
- ReOrg
- About ReOrg Displays version and copyright information
- Help Toggle help mode.
In help mode the mouse pointer changes its
imagery. When you select a menu item or a
gadget while in help mode, ReOrg shows you
a short explanation. You can leave help mode
by selecting the menu item "Help" again.
- Quit ReOrg Quits the program
- Settings
- Create Icons ? If this menu item is selected, ReOrg creates
a Workbench icon (.info-file) whenever you save
a settings file.
- Load Loads any previously saved settings file
Settings...
- Save Settings Saves the settings (state of all gadgets
and menu items) in the current settings
file (default = "ReOrg.prefs")
- Save Settings Saves the settings in any settings file
as...
Description of gadgets:
- Format This gadget specifies if the destination
disk is to be formatted.
- Off Do not format the destination disk.
For all disk writes CMD_WRITE is used.
(This only works if the destination disk
has been formatted previously;
default in one-disk-mode)
- On Only used tracks are formatted on the
first write access. Should usually not be
used for harddisks, but is useful for floppy
disks.
- All tracks All tracks of the destination disk
are formatted (necessary, if the
destination disk has not been
formatted before; default in two-disk-mode)
- Write verify If this gadget is activated, ReOrg checks
if data is written correctly (verify).
This slows down the optimization. For
hard disks verify ist usually not necessary.
- Workbench Mode If this gadget is activated, Workbench
icons will appear faster after optimization.
- Graphical sector If this gadget is activated, ReOrg
display graphically shows the user which sectors it
is currently working on during optimization.
This makes the optimization slightly slower.
- Advanced options This gadget opens a window that
contains options which are not needed
so often.
- Option file You can enter the name of an option file
in this gadget. Option files allow the
user to specify, that certain files should
be treated by ReOrg in a different way.
The format of the option file is described
below.
The option file name can be entered
immediately, or you can use the "Select"
gadget to select an option file in a
file requester. The gadget "Clear" clears
the option file name.
- Drive / These gadgets are scrolling lists that
FROM Drive / show all available drives. In one-disk-mode
TO Drive you must choose one device name, in
two-disk-mode, two different devices must
be selected.
- Mode Lets you choose between
- One Drive (one-disk-mode) and
- Two Drives (two-disk-mode)
- Start Starts the Optimization
- Cancel Quits ReOrg
Description of gadgets in the "Advanced options" window:
- FileExt blocks Specifies where FileExt blocks are
stored. For a detailed description:
See "6. Technical details"
- Partition Half Specifies where file contents are
stored. For a detailed description:
See "6. Technical details"
- Update disk date Normally, ReOrg increments the disk
creation data during optimization.
This is necessary to prevent ReOrg
from mixing up the old disk with the
new, optimized disk. If this gadget
is deactivated, ReOrg does not change
the disk creation date.
CAUTION: If you deactivate this gadget,
under certain circumstances your Amiga
might crash after the optimization !
- SIMULATE If you activate this gadget, ReOrg does
optimization not write the optimized data back to
only disk. This means, the optimization is
only "simulated". This is useful to
find out if ReOrg will issue error messages
during the actual optimization.
- Read Drive This gadget can be used to activate the
Geometry command TD_GETGEOMETRY. This command is
used by ReOrg to adjust to devices that
support multiple disk formats. At this
time, only "trackdisk.device" supports
multiple formats to support DD disks as
well as HD disks. However, ReOrg recognizes
HD disks in "trackdisk.device"-based drives
even when this gadget is deactivated.
So you only need to activate this gadget
if you have ANOTHER device that supports
multiple disk formats (e.g. special disk
drives on your SCSI bus).
CAUTION: If you activate this gadget for
a device, that does not understand
TD_GETGEOMETRY, your Amiga may crash !
So, usually, you should switch this gadget
off !
The function of this gadget has changed
since ReOrg V2.1.
- Safety Memory In this gadget you can specify the
amount memory that ReOrg should NOT use
as cache. Default is 150000 Bytes, but
you can reduce this value to 50000.
Or you can increase the value as high
as you wish, if you want to spare some
of your memory for other programs.
Values smaller than 50000 are not allowed,
because otherwise there might not be
enough memory left when an error occurs.
- Small file limit ReOrg stores large files in a seperate
area on your disk to speed up the access
to directory data. However, small files are
usually stored within the directory area
to speed up the access to those files.
This does not affect the speed of
directory accesses very much.
In the "Small file limit" gadget you can
enter the maximum size of files (in
blocks), that should be stored within
the directory area (default=2). Large
values slow down the directory access
("dir", "list"); small values slow down
the access to small files. When you
optimize boot disks (e.g. for games),
larger values can be useful.
There is yet another way to control ReOrg: If ReOrg
is started from Workbench, the ReOrg window becomes an
"AppWindow". This means, you can drop Workbench icons
in this window.
- When you drop the icon of a ReOrg settings file in
the window, ReOrg loads the settings file.
- When you drop a disk icon over one of the device
scrolling lists (Drive, FROM Drive, TO Drive),
ReOrg chooses the device name belonging to the
disk icon.
When the optimization is started, ReOrg first prompts
the user to insert the disk(s). After that, a status
window appears and ReOrg starts reading and processing
the disk directory.
During this phase (status = "scanning disk"), ReOrg may
be interrupted at any time even in one-disk-mode.
At the end of this phase, ReOrg once again asks the
user to confirm that the disk should be optimized.
In one-disk-mode, ReOrg must not be interrupted or
canceled after this message, or your disk will be
corrupt.
During the actual optimization (status = "moving blocks")
ReOrg shows how much time the optimization will approximately
need. This display is regularly updated.
After this phase has been finished, in two-disk-mode ReOrg
may format unused tracks on the destination disk and copy
reserved sectors to the destination disk.
After that, ReOrg asks the user to remove the disk(s).
Finally, ReOrg shows some statistical information about
the disk and the optimization.
During the optimization, the status window show the
following information:
- The number of directories and files, which ReOrg has
already processed ("done") and which ReOrg has
queued for later processing ("queued").
- The current cache usage. If this value reaches
100% at any time during the optimization, this
means that more memory could speed up the
optimization.
- The cache size (in absolute numbers, and relative
to the disk size)
- The current status of ReOrg. Possible states are:
- checking disk Before the actual optimization
starts, ReOrg checks if your disk
is a valid AmigaDOS disk.
- scanning disk ReOrg is reading the disk directory
and is calculating the layout of the
destination disk.
- awaiting user ReOrg is waiting for the user to
response confirm the start of the
optimization.
- preparing ReOrg is creating internal tables that
optimization are needed for the optimization.
- moving blocks ReOrg is optimizing the disk.
- writing bitmap ReOrg is writing the new disk
bitmap.
- formatting empty If the user selected "Format: All Tracks",
tracks ReOrg formats all unused tracks on the
destination disk.
- copying reserved ReOrg is copying reserved blocks
blocks (boot blocks etc.).
- The remaining time needed for the optimization (only
during the phase "moving blocks"). This value is only
an approximation of the remaining time needed. If source
and destination devices have a very different speed,
(e.g. "RAD:" to "DF0:"), the estimation is very inaccurate.
- A graphical display, how many percent of disk blocks
have already been moved. This percentage also corresponds
to the percentage of time needed for the optimization.
- If the user selected the gadget "Graphical sector display",
ReOrg displays on the right side of the window which sectors
are currently processed.
5. Error messages
-----------------
Error code Meaning
1 AmigaDOS error: The file size does not correspond
to the number of data blocks allocated to a file.
2 Device error: I/O error during read
3 Device error: I/O error during write
4 Device error: I/O error during the last write access
5 Device error: I/O error trying to switch the motor
of the source drive off
6 Device error: I/O error trying to switch the motor
of the destination drive off
7 AmigaDOS error: Invalid block number in
directory tree
8 AmigaDOS error: A block is used twice (corresponds
to the Disk-Validator error message "Key ### already set")
9 AmigaDOS error: A control block has an invalid
identification in the first longword (must equal 2)
10 AmigaDOS error: A control block has an invalid
type identification in the last longword (ReOrg
currently recognizes types -4, -3, 1, 2, 3, 4)
11 File error: Cannot open option file
12 File error: Cannot read option file
13 File error: Option file has an invalid format
14 File error: Option file has an invalid version
15 File error: Option file is too long (more than
65534 lines)
16 File error: Unexpected end of line in option file
17 File error: Invalid option in option file
18 File error: Invalid combination of options in
option file
19 Run time error: Not enough memory
20 User mistake: No FROM-device selected
21 User mistake: No device selected
22 User mistake: No TO-device selected
23 User mistake: FROM- and TO-device are the same
24 User mistake: FROM- and TO-device are incompatible
to each other
25 Device error: Cannot open device
26 Format error: Disk format unknown
27 Format error: Disk does not have a valid AmigaDOS
format
28 File error: Error writing the settings file
29 File error: Error reading the settings file
30 File error: Help file corrupt
31 Device error: I/O error during verify. When this
error occurs, you can cancel the optimization,
try again to write and read the blocks or ignore
the error.
32 User mistake: No disk inserted !
34 User mistake: Disk is write protected !
35 Device error: Difference between read and written
data during verify. When this error occurs, you can
cancel the optimization, try again to write and read
the blocks or ignore the error.
401 Device does not exist (Usually, this error should
not occur).
402 Device does not have one of the valid AmigaDOS
formats (DOS\0, DOS\1, DOS\2, DOS\3)
403 Block length does not equal 512 bytes.
404 The mountlist entry "SecOrg" is not equal to 0
(invalid format ?)
407 The mountlist entry "Reserved" is equal to 0
(invalid format ?)
408 The number of sectors per track is equal to 0
409 Error during 'Inhibit' (Allocating/freeing drive)
502 Warning: Invalid control block encountered while
moving blocks.
503 Warning: Invalid data block encountered while
moving blocks.
504 The mountlist entry "MaxTrans" is too small to
read a whole track. This warning usually just
means, that your controller does not initialize
its drive description properly.
505 Device error: Error during TD_PROTSTATUS
1xxx Internal Error: Error numbers larger than 1000
are internal errors, that should usually not
occur. If you get one of these errors, please
inform the author of ReOrg !
6. Technical details
--------------------
- Option "FileExt blocks"
Files larger than 34.3 kB (OFS) or 36 kB (FFS) require
"FileExt blocks" (also called FileList blocks).
ReOrg offers three models where to place these blocks
on the output disk:
1) "Front" : All FileExt blocks are placed immediately
behind the header block. This is the default
under Kickstart 1.2/1.3.
2) "Mid" : All FileExt blocks are placed behind the
first sequence of data blocks. This is the
default under Kickstart 2.0.
3) "Scatter" : FileExt blocks are scattered among the
data blocks.
Recommended Settings:
- If you want to be able to display the directory contents
of your disk under Kickstart 1.2/1.3: BE SURE TO use the
setting "FileExt blocks=Front". Otherwise the "dir"-command
gets even slower than it already is.
- Otherwise: usually "FileExt blocks=Mid" is best for disks
that are ONLY used under Kickstart 2.0. Sometimes,
"FileExt blocks=Scatter" can be useful, if large files are
read only sequentially using small program buffers (most
C-programs use very small buffers (512 bytes)). For those
programs sequential file access gets faster, if you
choose the setting "FileExt blocks=Scatter".
- Exception: When you reorganize Boot disks, for which you
NEVER read the directory under Kickstart 1.2/1.3 (e.g.
Game boot disks), the setting "FileExt blocks=Scatter"
often gives the best results - under Kickstart 1.2/1.3 as
well as under Kickstart 2.0.
- Another Exception: When the disk contains large files
which are accessed in relative mode (using Seek()),
you should NOT use the setting "FileExt blocks=Scatter".
- Partition half
It is possible to store file data mainly in the
- Upper or
- Lower
partition half. Usually there is not much difference
between both settings. The decision which setting
is better usually depends on the amount of data
on the partition.
- Options "Workbench mode" and "Small file limit"
For each file, ReOrg decides whether to store the file
contents behind the header block or in the data area.
- data stored after the header block:
- File access gets faster
- Directory access gets slower (particularly for
large files)
- data stored in data area:
- File access gets slower
- Directory access may get faster
When you use the option "Workbench mode", ReOrg stores
all "#?.info" and ".backdrop" files after the header block.
This makes Workbench icons appear faster. However,
directory access from the shell may become slower.
The option "Small file limit" makes ReOrg store the contents
of small files (default: up to 2 blocks size) after the
header block, to increase file access speed. This does not
slow down directory accesses considerably, but file access
to small files gets much faster.
If you only want to have fast directory access, you can set
this option to "0".
Directory accesses get fastest, if you switch off "Workbench
mode" and set "Small file limit" to "0".
Some details about the technical process of optimization:
- The "bitmap" of the source disk is not needed by ReOrg.
Therefore it is not necessary to "validate" your disk
before optimizing it.
- Before ReOrg changes anything on your disk, it
first checks the structure of your disk. However,
this check is not complete, i.e. ReOrg does not
detect all possible structural defects (btw, even
the AmigaDOS Disk-Validator does not detect and
correct all defects !).
When ReOrg reports an error in the first phase, it
has not destroyed or changed your disk yet in any
way. But when the phase "moving blocks" starts,
ReOrg must not be interrupted any more, because
in this phase ReOrg rearranges the disk layout.
- Anyway I STRONGLY RECOMMEND to THOROUGHLY check your
disk for structural defects before optimizing it.
Otherwise ReOrg might report an error in the
"moving blocks" phase and might even destroy your
disk (although this is very unlikely).
- If ReOrg stops or is interrupted in the "moving
blocks" phase, the following things happen:
- Your disk is displayed on Workbench as "DF0:REOR"
(DF0 being the drive that contains your disk).
- When you try to access your disk, AmigaDOS reports
"Not a DOS disk".
- The contents of your disk are TOTALLY UNUSABLE AND
COMPLETELY DESTROYED.
In this situation there is only one thing you can do:
!!! Reformat your disk ("format ... quick") and !!!
!!! restore your backup. !!!
Do not trust "hints" from computer magazines telling you,
you could still repair parts of your disk. I explicitly
warn you:
!!! Do not try to repair your disk using tools like !!!
!!! "disksalv", "fixdisk", "diskdoctor" or any commercial !!!
!!! disk tools ! !!!
!!! Although you might by coincidence really restore some !!!
!!! of your files, you will most certainly "restore" a lot !!!
!!! of corrupt files, but you will not get an error !!!
!!! message from your disk recovery tool. This is !!!
!!! especially true if your disk has the FFS format. !!!
!!! "Repairing" corrupt program files may very well lead to !!!
!!! MASSIVE computer crashes in the future. So: Always !!!
!!! restore your backup when ReOrg does not complete the !!!
!!! "moving blocks" phase ! !!!
7. Option file format
---------------------
Most users will probably not needed option files.
However, option files are useful to make some "final"
optimizations, e.g. before disks are distributed.
Especially when you optimize game boot disks, a
"perfect" optimization using option files may save
you some seconds when you boot from your disk.
Option files allow you to change the settings of
the "FileExt blocks" option and to specify the
placement of data blocks for individual files.
These settings override the global settings for
single files.
Example: You want to optimize a game boot disk, that
contains a lot of files. You therefore used
the global setting "FileExt blocks=Scatter"
(An explanation, why this makes sense, can be
found in the section "6. Technical details").
The disadvantage of this setting is, that
relative accesses to large files become slower.
When you know, that your game often accesses a
single large file in relative mode (let's say
the name of this file is "graphics/dungeon.gfx"),
you should change the setting of "FileExt blocks"
to "Front" for this single file only. This kind
of settings can be specified in option files.
Option files are ordinary ASCII text files. You can use
any ASCII text editor to create and edit them (e.g. MEmacs).
Format:
1st line:
$1
(A dollar sign ("$") and the digit One ("1") in the first
two columns of the line)
all other lines:
options:file name:comment
valid options are:
I0 Data blocks of this file are not placed near
the header block (default)
I1 Data blocks of this file are placed near the
header block (file access gets faster, directory
access gets slower)
E0 The same as "FileExt blocks=Front" for a single file.
E1 The same as "FileExt blocks=Scatter" for a single file.
E2 The same as "FileExt blocks=Mid" for a single file.
You can combine several options in a single line
(e.g.: E0I1:file name:comment)
The above example:
$1
E0:graphics/dungeon.gfx:any comment
Some more notes about the file format
- The file name must be specified relative to the root
of the disk, i.e. please do not write "/test/name.doc",
"sys:test/name.doc" or "diskname:test/name.doc", but
only "test/name.doc"
- Spaces and other special characters may occur in the
file name. You need not (and must not) use quotation
marks to surround the file name !
- Patterns (e,g, "*.txt" or "#?.txt") are not allowed !
8. Program version, update info
-------------------------------
- V2.33 (Rev 99, 30.09.1992, 5th release)
Changes since V2.32:
- Fixed a bug that could cause deadlocks during
the "moving blocks" phase at "99% finished"
- V2.32 (Rev 94, 16.07.1992, 4th release)
Changes since V2.31:
- ReOrg can now handle Kickstart-1.1 compatible
Mountlist/Rigiddisk entries. This prevents
problems with A209x controllers and the old
"prep" program.
- V2.31 (Rev 88, 04.07.1992, 3rd release)
Changes since V2.3:
- ReOrg no longer crashes, when you move the ReOrg window
to the far right side of the screen, hit "start" and
acknowledge the requester
- The "moving blocks" phase now contains additional
code to recognize and circumvent deadlock situations
- Error #33 has become Warning #505 and can now be
skipped by the user
- V2.3 (Rev 75, 20.06.1992, 2nd release)
Changes since V2.1:
- ReOrg now correctly works with cache sizes
larger that 8 MB
- all windows use the font "topaz 8"
- ReOrg no longer crashes if an error occurs before
ReOrg has opened its window (e.g. if you specify
a wrong name for the initial settings file)
- ReOrg uses the "DrawInfo" structure to make all
texts readable even on 2-color screens
- obsolete ".info" files are treated like all other
"#?.info" files
- Real double buffering has been implemented for
all read accesses as well ==> speed increase
- menu texts are displayed in the screen default
font
- asynchronous I/O is used even in one-disk mode
- slight changes in the "moving blocks" phase to
increase speed
- Handling of TD_GETGEOMETRY greatly improved.
Crashes are much less likely now.
- Error messages #406 ("MaxTransfer to small") has
become a warning now (#504) and can be skipped by
the user
- ToolType "PUBSCREEN" works correctly
- ToolType "SCREENMODE" implemented to force ReOrg
to open on an own custom screen
- If read/write errors occur during the "moving
blocks" phase, the user can now "repeat" the
I/O or "ignore" the error. This means the
optimization can be finished even if errors
occur.
- The mountlist entry "Mask" is used to prevent
problems with old DMA controllers in combination
with turbo boards.
- Compatibility of Verify improved:
- No more errors when the device does not recognize
CMD_UPDATE
- ReOrg automatically switches to (slower)
synchronous verify if the device does not
support (faster) asynchronous verify.
- Fixed a problem at the end of the optimization,
that occured if the volume had the same name
as the device.
- V2.2 (several Revs, intermediate internal version)
- V2.1 (Rev 49, 28.05.1992, 1st release)
In addition to ReOrg V2.33, there is another current
ReOrg version, that also runs under Kickstart 1.2/1.3.
The version number is V1.1.
If you have ReOrg versions V0.9, V0.99 or V1.0,
please DELETE them. They are internal beta-test versions.
I will try and further improve ReOrg V2.33 if I have
time for it. Registered users will get a notification
when new versions of ReOrg get available, that contain
significant changes or enhancements.
But I will probably not change the Kickstart 1.2/1.3-
compatible ReOrg version V1.1 any more. I guess that
most Users will upgrade to Kickstart 2.04 after some
time anyway, so they can use ReOrg V2.33.
Besides ReOrg V2.33 contains some improvements that
have not been implemented in ReOrg V1.1. One of them
is: ReOrg V2.33 needs much less memory to optimize large
hard disk partitions than ReOrg V1.1.
In order to be able to improve / correct ReOrg, I would like
to ask every user to do the following things:
- send me the registration fee
- send me bug reports, if you find any bugs
- give me hints how to improve ReOrg
Thank you very much in advance !
My personal future plans for ReOrg, if I have time for them:
- Implement an option to convert disks between the
"ordinary" disk formats to/from the International
FileSystem format
(i.e. DOS\0 <--> DOS\2, and DOS\1 <--> DOS\3)
- Support for "locale.library" to adapt ReOrg to
different languages
I will be thankful for other ideas.
9. Acknowledgements
-------------------
Thank you to all beta-testers of ReOrg !
These are:
Thomas Esser, Oliver Kasper, Carsten Lechte, Holger Lubitz,
Michael Rohrdrommel, Kai Siering, Christian Soltenborn,
Christian Wolf and Michael Zielinski.
Thank you to Christian Wolf for distributing
ReOrg via FTP !
... last but not least many thanks in advance to all
ReOrg users who send me the registration fee !
Holger Kruse
