Magazyn Amiga Shareware Floppies

home *** CD-ROM | disk | FTP | other *** search

/ Magazyn Amiga Shareware Floppies / ma03.dms / ma03.adf / Reorg / ReOrg.doc next >

Wrap

Text File | 1992-10-04 | 43.8 KB | 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