Download by anonymous FTP from: ftp://ftp.ethoberon.ethz.ch/ETHOberon/Native/Update/
File system concept
Comparison of the Oberon file systems
File systems in the beta version
Partition management with Oberon
Disk image file
Partitions viewed by Linux-based Oberon
Oberon file system and foreign file systems
Multiple Oberon partitions on a machine
Oberon installation and installation updating
Reconfiguring Oberon on start up
Backup / Restore methods
Beta version specialities
Note 1: The first beta version appeared on 20.03.2000 and was updated on 25.04.2000, 26.05.2000 and finally on 08.12.2000. In addition, an alpha version, including several changes and extensions, was made available on 13.05.2001 and is being updated regularly since then. The respective Beta version and Alpha version change logs contain detailed chronological accounts of the modifications made up-to-now. This document places the accent on the alpha version, while the beta version specialities are relegated in separate sections. Readers using the beta version will notice a few major differences but will also get a preview of what the alpha version will bring, if they are tempted to upgrade from their current beta to alpha.
Note 2: To determine which version you are currently using, look at the date on the second line in the log, just after booting your system. If you have other Oberon partitions (type 76) on your machine, with an installed Oberon OS, look for the date in Kernel.Obj.
If you have further questions, read the FAQ dedicated to this alpha/beta version. To find out whether your machine can host Native Oberon or not, consult the Hardware Compatibility List.
This version of ETH Native Oberon introduces a new file system concept, a new generic driver concept, a number of new features and numerous improvements and corrections of the previous release.
Disk: IDE0, 8063MB = 16514064 * 512, CHS: 16383*16*63, Maxtor 90845D4, mntcnt=1 IDE0#00 0 16514064 8063MB --- (Whole disk) IDE0#01 63 819252 400MB 6 * DOS FAT16 >= 32M IDE0#02 819315 4176900 2039MB 6 DOS FAT16 >= 32M ...Each partition can host a file system of which there are more than operating systems. With its new generic file system support, an active Oberon has access to the data of co-resident partitions hosting a supported file system (FS). The supported file systems are listed in the OFS.Alias section of Oberon.Text . They are:
Disk: Diskette0, 1440KB = 2880 * 512, removable, CHS: 80*2*18, mntcnt=1 Diskette0#00 0 2880 1.4MB --- (Whole disk) [mounted]
These file systems perform anonymous file garbage collection on-the-fly. Previously, file GC was performed only when Oberon was started.
Each file system is characterized by a number of states:
The implementation of files on a random-access store
The scheme chosen in Oberon favors short files (< 64KB) but to keep the on-disk structure small yet still allow large files, each file header conforms to the following schema:
FS Sector Sector Extens. Index Header Max. file size table table size size size (bytes) size size (bytes) (bytes) AosFS 4'096 128 1 1'048'576 568 4'295'491'016 NatFS 2'048 64 12 512 352 12'713'632 CeresFS 1'024 64 12 256 352 3'210'912The first data sector pointer points itself, the sector containing the header. The on-disk structure is similar to the internal organization of Unix files [Bac86].
Sector pointers are represented by sector numbers of type LONGINT. Actually, the numbers are multiplied by 29, the sector factor. This implies that any single-bit error leads to a number that is not a multiple of 29, and hence can easily be detected. The Scavenger program takes profit of this.
The file directory
The Oberon system uses a B-tree structure with the following characteristics for its file directory:
On a page, space must be available for 2N elements and for N + 1 references to descendants. Hence N is immediately determined by the size of a page and the size of elements. In the case of Oberon, names are limited to 32 characters (bytes), and the object is a reference to the associated file (4 bytes). Each descendant pointer takes 4 bytes, and the page size is given by the sector size (SZ) minus the number of bytes needed to store m (2 bytes). Hence N = ((SZ - 2 - 4) DIV (32 + 4 + 4)) DIV 2
FS SZ N DirPgSize AosFS 4096 51 102 NatFS 2048 25 50 CeresFS 1024 12 24The number of directory entries stored in the tree depends on the tree height. The maximum number is given by the expression: MaxElems = 2*N * SUM(i:=0..Height-1, (2*N+1)^i)
Height 1 2 3 4 FS AosFS 102 10'608 1'092'726 2.145 E+09 NatFS 50 2'600 132'650 6'765'200 CeresFS 24 624 15'624 390'624Inside the directory page, a binary search among the elements is used (there are between N and 2*N elements in a page). Hence assuming you have more than 10608 files in an AosFS, the tree will have an height of 3 (3 directory pages are accessed in the worst case) and a maximum of 3 * 2LOG(102) = 20 comparisons are needed (this is small compared to the disk access time). Besides that, caching can make accesses faster (usually the root page of the file directory stays in the cache).
AosFS limit values
The maximum file size is 4.0GB because of its triple index structure, but its is effectively limited to 2.0GB because of the 31 bit value for Set and Pos parameters.
The maximum volume size or partition size is 282.48 GB, because
BIOS imposes a limit of: 1'024 cylinders * 256 heads * 63 sectors = 16'515'072 physical sectors
to divide by the sector factor (29)
resulting in 569485 physical sectors of 512 bytes.
A typical workable Oberon partition for a full system starts at about 40MB. Cfr. ShowAosFSLimits
A partition is addressed as "dev#part" where dev is the physical device designator such as IDE0, IDE1, Diskette0 (for the A drive) or Diskette1 (for drive B), and part is the sequence number of a partition on the device. Oberon collects the partition information from the partition table located in the first sectors of a device. A summary of the disk partitioning is displayed by executing Partitions.Show .
Example Partitions.Show detail ~:
Disk: IDE0, 8063MB = 16514064 * 512, CHS: 16383*16*63, Maxtor 90845D4, mntcnt=1 IDE0#00 0 16514064 8063MB --- (Whole disk) IDE0#01 63 819252 400MB 6 * DOS FAT16 >= 32M IDE0#02 819315 4176900 2039MB 6 DOS FAT16 >= 32M IDE0#03 4996215 401625 196MB 79 Native Oberon or QNX Posix IDE0#04 5397840 11036655 5388MB 5 Extended IDE0#05 5397903 401562 196MB 76 |Native Oberon, Aos [mounted] IDE0#06 5799528 2056257 1004MB 131 |Linux fs ...The first line describes the disk:
Disk: Diskette0, 1440KB = 2880 * 512, removable, CHS: 80*2*18, mntcnt=1 Diskette0#00 0 2880 1.4MB --- (Whole disk) [mounted]
In the example, Partition 0 is a virtual partition that spans the whole disk. Devices that do not have a partition table, like a diskette or a CD, have only a partition 0. The disk name of the first diskette drive is "Diskette0" and the partition's name is "Diskette0#00". A ZIP disk can, in principle, have several partitions, as it can feature a partition table.
Each subsequent line informs on the location, size and type of a partition or free space. The data is, for a part, extracted from the partition table located in the MBR.
Each partition is assigned a partition type (see column 5 in the example) which identifies the file system contained in the partition. The partition type of the ETH Native Oberon is "76" (decimal) (partition hosting the new AosFS). More than one partition with partition type "76" may exist on a machine. That is not the case for the previous Native Oberon which uses partition type "79" and distinct other values for further partitions. The file system used there is named "NatFS".
An active partition (see Partitions.Activate), is marked with an "*".
Depending on the installed hardware, the partition table is displayed after an appreciable time lapse. As an indication, it may take up to 10 seconds to scan and collect the information for a ATA/IDE device. This delay is well noticeable on older computers.
Note that changing the partition type makes it unaccessible to other operating systems! If you accidentally change the type of the wrong partition, you can always change it back, provided you have not made other changes to it in the mean time.
The BootFile is the "kernel" of Aos. The file contains a statically linked image of the basic modules of the active object runtime, the dynamic module loader, at least one file system and at least one disk driver. This makes the partition bootable. BootFile is "Native.Bin" by default. FSRes is the amount of space that must be reserved for hosting the data. By default, 512 KB are reserved. Later on, after the partition was created, if the boot loader must be updated without a need of formatting the partition, you must use the command Partitions.UpdateBootFile. Currently, Native.Bin is missing and a warning is issued informing that the partition is not bootable. Boot your machine using the Oberon0 diskette to perform a partial installation or an installation update to access Native.Bin.
If a diskette is to be used solely as backup medium, set FSRes to 1 (0 will not be accepted) since the default value would amputate most of the available space.
A Partitions.Check command is executed implicitly. If the partition has been checked before, the check process can be safely interrupted by pressing the spacebar. This will speed up the format operation.
The configuration strings are used when Oberon is started by the boot loader and they can be also modified at that time.
Limitation: This command can only be addressed to a partition on a device using 512-byte blocks. A CD-ROM uses 2'048-byte blocks for example and a TRAP would be induced. The config strings can be inspected and modified only at start time.
Practical hint: during an Oberon installation, one has interest to execute Config.BootPartition menu ~ always, even when a boot diskette is going to be created. In case the diskette gets lost or damaged, create a new diskette quickly, leaving out the configuration part, and to recover the configuration, execute Partitions.GetConfig dev#part followed by Partitions.SetConfig Diskette0#0. In certain circumstances, it may be difficult to decide which display driver was selected initially.
Technical hint: The configuration data is stored in sectors 4 to 7 of the partition - cfr. Partitions.ShowBlocks command below.
In particular, Partitions.FileToPartition Diskette0#0 Oberon0.Dsk ~ is used during an Oberon installation to create an Oberon-0 boot diskette from the disk image file Oberon0.Dsk.
Note: In versions prior to 13.05.2001, the syntax was: Partitions.PartitionFileTo dev#part filename [blocks] ~ which meant: write the first blocks to the partition.
The MBR of a disk can be saved to a file (MBR.Bin) by executing Partitions.PartitionToFile dev#0 MBR.Bin 0 1 ~
Note: In versions prior to 13.05.2001, the syntax was: Partitions.PartitionToFile dev#part filename [blocks] ~ which meant: write the first blocks of the partition.
Hint: This command must be considered as a technical utility, also paired with Partitions.FileToPartition. It can be used with any operating system and is useful to remove or to write a LILO boot record for instance. This command is not equivalent to Partitions.FileToPartition dev#part filename 0 1 ~ !!!
It writes only the boot loader code, the first 446 bytes, in the MBR, leaving the partition table unchanged. It is the equivalent of the DOS command fdisk /mbr . On the contrary, Partitions.FileToPartition not only writes the boot loader in the MBR, it also writes the partition table, which can be harmful.
Cfr. How It Works - PartitionTables.
Troubleshooting a boot problem with this command
If your Oberon system does not start properly and simply stalls and displays "OBE", the Native boot loader does not find the second sector. Execute: Partitions.ShowBlocks IDE0#02 0 8 ~ to write the first 8 sectors of the partition. Sector 0 (the first sector) should have "OBERON" close to the start, and 2-byte signature "55 AA" at the end. Sector 1 must have two AA 55 bytes at the start. Example:
IDE0#02 0 00000000 EB 29 90 4F 42 45 52 4F 4E 00 00 00 02 02 08 00 .).OBERON....... 00000010 04 E0 00 00 00 F0 09 00 3F 00 40 00 40 23 03 00 ........?.@.@#.. 00000020 C0 90 0F 00 80 00 00 03 00 00 00 FA EA 31 00 C0 .............1.. ... 000001F0 72 72 6F 72 21 07 00 6F 62 65 72 6F 6E 00 55 AA rror!..oberon.U. IDE0#02 1 00000000 AA 55 66 A1 1C 00 66 A3 06 07 BB 00 08 B9 04 00 .Uf...f.........It is important that the four bytes at offset 1CH in sector 0 designate the sector number of the boot sector. In the example: 40 23 03 00 (reversed in little-endian order) -> 00032340H = 205632 decimal
The last value must match what appears in the first column for the partition after executing Partitions.Show detail ~
IDE0#02 205632 1020096 498MB 79 Native Oberon or QNX Posix [mounted]Another thing to check is that the byte at offset 24H is the boot drive number (80H in the example). This should be 0 for diskette A:, 80H for the first BIOS disk drive, 81H for the second BIOS disk drive, etc. In practice, the rule is relaxed since the software will accept either 81H or 80H.
Your configuration should be visible from sector 4 to 7 (or it could be all zero if you always boot via noboot.exe).
The "active" marker has no meaning when:
Active partition on a disk drive other than the first one: It can be booted too if the machine System Setup allows to change the boot sequence.
More than one active partition: The normal case is to allow only one active partition on a disk. If more than one is active, as can easily be achieved, it is expected that the first one found in the physical order is booted, but that can depend on the MBR code. One boot manager (?) was observed which did present a menu with the active partitions.
Oberon implements a simple sector-based cloning method in a pair of commands Partitions.PartitionToFile and Partitions.FileToPartition for cloning a single partition. The sectors of a partitions are copied to and from the intermediate file without knowledge of the underlying file system structure. The intermediate file is usually called a disk image file, or simply disk image. The advantage of the method is that it can not only be used for an Oberon partition but also for any existing operating system.
Usually, a disk image will reside on a server. For example, Oberon0.Dsk is a disk image, more precisely a diskette image, which resides on the ETH ftp server ftp://ftp.ethoberon.ethz.ch/ETHOberon/Native/.
Cloning is also useful for moving a partition to another on the same or another disk on the same computer. Keep in mind that a third partition must offer enough free space for storing the disk image. Given that an Oberon partition is normally no larger that 50MB, this kind of cloning can be considered realistic and practicable too because it is fast. Partitions of other OSs are usually much larger and finding enough free space is probably out of question. Cloning is not apt to resize a partition - cfr. command OFSTools.GenCopyFiles
This image file is at the base of the installation or update of each Oberon system. With it and with the Partitions.FileToPartition command, an Oberon-0 boot diskette is created. Booting from this diskette, starts Oberon-0 which is a small ramdisk-based system for configuring and installing a real, full-fledged Oberon system. This boot diskette is a good example of Oberon system on a diskette.
The image file is created by a process completely described in the section "Installation diskette" in Native.Tool.
Oberon utility diskette
The Oberon Utility Disk is another example of Oberon system on a diskette. The image file is created by a process completely described in the section "Utility diskette" in Native.Tool.
Disk image format
A disk image can also be processed by other popular disk image programs. For example, the Oberon-0 boot diskette can also be created with:
Example Partitions.Show detail ~:
Disk: oberon.dsk / 61438 * 512 = 29MB / GetCHS: unsupported / mntcnt=1 oberon.dsk#00 0 61438 29MB --- (Whole Disk) / mounted Disk: Diskette0 / removable / GetSize: no media / mntcnt=0
All the remaining Partitions commands are not applicable in that context. The configuration is not changed with Partitions.SetConfig but by editing oberon.cnf.
Like in Native Oberon, a file system must be mounted prior to accessing it. You can mount a LinuxFS or a Native Oberon partition accessed with Linux.OpenDisk.
Example: The full filename of Oberon.Text on a newly installed system is SYS:Oberon.Text .
A NamePlate gadget displays the filename at the beginning and the prefix (or directory) at the end, so that the filename is always visible. The prefix may be hidden when the filename is long. A MM click on a NamePlate causes the full name to be displayed in the System.Log.
An Oberon system can access not only the data of its own file system type AosFS but also data in other Oberon partitions and foreign file systems. Access to other file systems is controlled by the commands of the OFSTools module.
Example: OFSTools.Mount AOS AosFS IDE2#5 ~
After execution, a file "My.Text" residing in IDE2#5, the fifth partition on device IDE2, will be accessible with the name "AOS:My.Text".
The second and the third parameters are cache specifications. No cache is installed by default. Cfr. OFSTools.InstallCache command.
The fourth parameter is the file system type expected on the partition (AosFS in the example). The valid types are listed in the OFS.Alias section of Oberon.Text . Although it is conceivably possible for the system to work out the correct file system type to use, deducing it from the dev#part value, it was decided to have the user specify this, as it is more robust.
dev#part in the 5th parameter specifies the device and the partition to mount. It hosts either an AosFS, a NatFS or a FatFS file system. A FatFS may be a DOS or Windows FAT FSs; that is, FAT12, FAT16 and FAT32. Files can be exchanged between these FSs and that of an Oberon system using the familiar System.CopyFiles command. System.RenameFiles, System.DeleteFiles and System.Directory may be used too and files can be opened directly as usual. Further, the FAT.Tool allows access to the extended capabilities of the FAT file system that Oberon does not support, i.e. directories, file attributes, and so on. Also a DOS-formatted diskette or a ZIP disk can be mounted.
The optional ",R" parameter gives read-only access to the FS. For example, during the installation of a new Oberon system, you are invited to execute:
OFSTools.Mount SRC NatFS Diskette0,R ~ This gives read-only access to the mounted Oberon-0 diskette containing an archive of the Oberon modules to install. The diskette may be write-protected or not. Do not attempt to mount a write-protected diskette without specifying the ",R" parameter. A TRAP will occur.
Mounting a diskette causes the diskette LED to light and to stay lit until an Unmount command is issued. This should draw your attention because you must unmount the diskette before changing the medium.
The optional ",X" parameter is only for use when mounting a FatFS. This option forces the FAT driver to ignore the clean shutdown flag of the partition and to mount the partition for read and write. If the shutdown flag is not set, the partition is mounted read-only to prevent possible data corruption. This situation is reported in the Kernel log.
About the clean shutdown flag: The flag indicates that a partition was properly unmounted. If Oberon crashes, the flag will not be set for a partition which was mounted. It is a good idea to run a disk repair utility program, such as the MS-DOS Scandisk, on a FatFS: if Scandisk fixes an error, it sets the clean shutdown flag. If no error is detected, Scandisk does not set the flag, although it should.
params in the 5th parameter depends of the FS specified in alias, as is described below.
Practical hint: If you want a file system to be mounted when you start the system, you can place a Mount command in the System.InitCommands section of Oberon.Text .
RamFS size sectorsize ~
Mounts a file system residing in main storage, thus outside of the device / partition hierarchy and which need not be formatted. The RamFS parameter is followed by the size in sectors, followed by the sector size in bytes. This file system is provided as a user convenience for storing temporary data that will be purged when Oberon is terminated.
FileFS filename ~
Mounts an existing Oberon hosted in a file specified in the next parameter. Prior to this, the hosting FatFS must be mounted. This command variant makes it possible to exploit legacy data in former DOS-based Oberon systems.
Example: OFSTools.Mount FAT FatFS IDE2#5 ~ followed by: OFSTools.Mount DFS FileFS FAT:Oberon.Dsk ~
LinuxFS path ~ (Linux-based Oberon only)
Mounts a Linux file system found along the specified path. Refer to the special Linux section below.
Accessing the file system of an earlier Native Oberon release
First, use Partitions.Show to list all partitions, locate the target partition and select it. Then, execute: OFSTools.Mount NAT NatFS ^
Accessing a Linux file system from Linux-based Oberon
Accessing a Native Oberon sub-system from a Linux-based Oberon
Also take care not to unmount a file system before all viewers displaying documents residing on that file system are closed, otherwise you will induce a series of TRAPs.
Important: The FS which is automatically mounted at boot time cannot be unmounted. The status (boot) is revealed by OFSTools.Watch .
Later on, the order of the FSs can still be verified by executing OFSTools.Watch or System.Watch .
The order of the mounted partitions is important. In the example, WRK comes first, and then comes SYS. This means that when you load a file without specifying a prefix, the system will search through all the mounted FSs in their order, until the file is found. For example, if you load a file called "My.Text", and the WRK FS does not include such a file, then a file in SYS will eventually be opened, if it exists.
In contrast, when storing a file without an explicit prefix, the file is always stored on the first file system (WRK: in this case). To avoid confusion, it is best to always specify a prefix when creating a new file. The TextDocs gadget helps by always displaying the complete filename, including the prefix, in the NamePlate.
To direct the placement of files, as for instance when compiling new .Obj files, you may choose between:
If free space is low, remember that there exists no direct Oberon tool to resize an Oberon partition. Cfr. Partition backup.
To give another example, a RAM-based system installed immediately after booting from an installation diskette Oberon-0:
RAM: GCN2KFS on RAM0 (boot) 1072KB of 2048KB freeA 2MB RAM disk is created by default by Oberon-0. That means at least 3MB are needed for the installation. If needed, Oberon can run in less than 3 MB memory.
The syntax is not too intuitive but the command is really powerful and useful for preparing a batch of filenames. The easiest way to see how the command works is to try it out. This is safe, as it does not have any effect itself, other than generating a text that you can review and execute.
Copy or resize a partition
Assume that valuable data is stored in SYS: and that BACKUP: is a free partition on a system. The power of the command OFSTools.GenCopyFiles SYS: BACKUP: "SYS:*" ~ is particularly impressive in these two usually non-trivial applications:
Afterwards you will see the new devices in the Partitions.Show display. To see trace information displayed by these drivers, use System.OpenKernelLog .
Additional file systems
To create a new file system, you first have to create a partition by executing a Partitions.Create or a Partitions.ChangeType command. The next step is to format the partition with AosFS by executing a Partitions.Format command. After formatting the partition, mount it with an OFSTools.Mount command, e.g. with the parameters USR AosFS dev#part. If you want the file system to be mounted when you start the system, you can place this command in the System.InitCommands section of Oberon.Text . You can now access files on the new file system using names like: "USR:SomeFile".
You can also create Oberon file systems on removable media like diskettes and ZIP disks (driver available). In the case of removable media, you have to be careful to unmount the file system before removing the media again, to cleanly update the file system on the media. This is done using the OFSTools.Unmount command.
Suggestion for assigning partition prefixes
One should use a small number of partitions. The problem with having too many partitions is that they have to be preallocated, and one has to live with a bad allocation. If the SYS partition is too small to install a new release, what do you do? If it is too big, space is wasted. The recommended partition size starts at 40 MB for a complete release, leaving approximately 40% of user free space, but users may also elect to set their files apart in a HOME partition, as is explained below.
The Shark network computers at the ETH had three:
SYS: for read-only shared system files
RAM: for a ram disk
HOME: for the user's own files
On a PC, a recommended number is two:
SYS: for the installation
HOME: for the user's own files
It is recommended to make HOME: the default file system by executing OFSTools.SetDefault HOME ~ , at best when Oberon is started by adding it to the System.InitCommands section of Oberon.Text . To make this quite visible add System.Watch to that section too.
Files with identical names in different file systems
This may be the source of a serious problem, with .Obj files in particular. When a module X is loaded, the module loader simply tries to open file X.Obj (no prefix). The file system will search through the search path (in System.Watch order) until X.Obj is found, and module X will be loaded from that file system. If you have multiple copies of X.Obj on different file systems, the search path order determines which one is loaded. This can be to the least confusing and can also lead to a catastrophy with TRAPs and system lockup. The best is to name modules uniquely (by registering a prefix in the module registry on the Native home page), and to avoid duplicate .Obj files.
Installation of new release
To install a new release without impairing or destroying the working system, say for testing it, one creates an additional partition for the new release. Then, the current file system (SYS:), the new FS (also SYS:) and the user FS (HOME:) can be managed as two pairs: current + HOME and new + HOME. Obviously, with such a setup you do not risk to overwrite some of the SYS: files adjusted to your personal preference, but these particular files must also be customized in the new system. Modified files can easily be spotted by executing System.Directory SYS:*.Bak resulting in a list, which will probably contain some of these names:
Mail.Sig.Text - (your mail signature)
MailMessages - (your mailbox)
News.Sig.Text - (your news signature)
and possibly a few more *.Tool file names that have been adjusted. Follow the installation instructions to install the new release and start it. Mount the old FS under a name of your choice, e.g. OLD. Most of the files listed above may be copied to the new FS, except Oberon.Text which must be merged with the the new one, because some new settings may have been added in the new release. Open OLD:Oberon.Text and SYS:Oberon.Text and copy the old settings into the new text. It might be a good practice to highlight your private data in color.
A MailMessage.Bak file will only show up after having executed Mail.Collect or after having deleted 100 messages.
There remains to organize to start either system at will. Many alternatives are offered: make them bootable from diskette, from a boot manager or by activation. Whereas booting from diskette is always possible, the alternatives are conditioned by the boot manager or the partitions' position on the hard disk(s).
Upgrading an installed Oberon
If you re-install Oberon in the same partition or upgrade it, the risk of overwriting files exists in principle, but the install procedure takes care of creating a .Bak file for each file with suffix ".Text", ".Tool" or ".Mod". Only those files listed in the previous section are really 'critical' and could be lost by erroneous handling (*). The installation itself is simplified compared to a full installation. Indeed, a partition is already present, hopefully of a suitable size, and the FS is also present. Formatting the FS is thus not required. Instead, the boot loader must be replaced with Partitions.UpdateBootFile. After the installation, copy back the critical files from their .Bak version or from a special backup version. Do not simply copy Oberon.Text, because some new settings may have been added in the new release. Open Oberon.Text and Oberon.Text.Bak and copy the old settings into the new text. It might be a good practice to highlight your private data in color.
(*) E.g. by attempting another run of the installation before completing the current one. As a measure of precaution, you may thus backup them prior to the installation in any of the manners described in the next section.
Cfr. Configuration strings
OBERON loading... BootVol=IDE0#9 MT=PS2 ... OBL>Enter "h" (for help) to recall the rules for replying to the Oberon Boot Loader (OBL) prompt (terminate each reply with a carriage return):
name=val - set config string name= - delete config string c - continue booting w - write config to boot deviceEnter a config string pair and terminate with a carriage return. Since version 2.23 the name strings are no longer case sensitive. To make the changes permanent, enter "w" and the configuration will be written back to the boot device. To continue with booting, enter a final "c".
If noboot.exe is used to start Oberon (via DOS or MS-DOS mode in Windows 95/ 98 (not ME)), the boot process is also interrupted but the editor of choice determined by a SET Editor= command is called to edit the configuration stored in the Native.Par file. When the editor is exited, booting is resumed. If no editor is defined, booting proceeds normally without giving an opportunity to modify Native.Par.
Obviously, config strings can also be changed by editing Native.Par whenever required. Only the size of the file containing Oberon (in the Linux file system) can be changed in Linux-based Native Oberon.
File backup/restore to a mountable file system
Backing up in another file system (AosFS, NatFS, FatFS) is made possible by the mounting / unmounting facility described in Oberon and foreign file systems. A batch of files is best copied from one file system to a another using OFSTools.CopyTo. The same command is used to restore the files. Alternatively, the backup / restore operation can be conducted by executing System.CopyFiles. The command with a list of filenames is conveniently created by an OFSTools.GenCopyFiles command.
In spite of their limited storage capacity, diskettes are still a favorite backup medium, given the small average file size of Oberon modules and object files. Diskettes are exploited in the same way as hard disks, except that they feature a single partition of very small size, containing a mountable file system. Note that the AosFS can waste space in comparison with the NatFS and the FatFS. The classical drive letters "A" and "B" are not used anymore in commands, except in the Backup.Tool commands described next.
Since Oberon operates with long filenames, storing files to a FatFS may run unexpectedly fast into a capacity problem. The root directory in the file allocation table can contain 512 entries at most. In other words, there can be at most 512 files and folders in the root directory. To store long filenames and folder names, and their associated 8.3 aliases, one can run out of directory entries with fewer than 512 files or folders in the root directory. The work around is to move a batch of files to a work folder in the root directory.
Files are copied from a partition to a diskette using Backup.WriteFiles, and are restored to the partition using Backup.ReadFiles. Backup.Tool provides the details. For doing that, a diskette does not need mounting. Filenames are limited to the 8.3 format.
Files backed up on Windows Oberon using the DOSBackup tool can be restored on Native Oberon executing a DOS.BackupDirectory "a:/" command. This will produce a DOS.Copy command with the relevant filenames ready for editing before execution. The restored files will recover their Oberon names instead of the 8+3 names enforced by a DOS.ReadFiles command.
Backup on server via FTP
Oberon is inherently fit for communication, FTP in particular. A graphical user interface is at hand for uploading / downloading files to a remote server but the NetSystem.Tool provides down to earth commands to achieve the same goal.
Copy the partition to another one and restore it.
Copy the partition to a disk image file and restore it.
The Unzip, OldFiles and FileUtils tools, documented in Chapter2.Text , have been removed.
Partitions.Show ["detail"] ~ The command tells which drive letter is associated with each DOS/Win partition. This information is unreliable since it depends on the version used, and moreover, it is foreign to Oberon. This non-facility was dropped in the alpha version which features a more versatile FatFS.
Disk: IDE0, 8063MB, Maxtor 90845D4 IDE0#00 8063MB --- (Whole disk) IDE0#01 400MB 6 * c:/ DOS FAT16 >= 32MThe drive letter is necessary for mounting a DOS-based Oberon and for managing files with the DOS.Tool commands.
OFSTools.Mount prefix DosBasedFS filename ~
Mounts the file system of an Oberon system residing in the file specified in the next parameter. The file is located in a FAT16 partition.
E.g. OFSTools.Mount DOS DosBasedFS c:/oberon.dsk ~
OFSTools.Mount prefix FileFS filename ~
Mounts a FileFS of an existing Oberon in a file specified in the next parameter. Prior to issuing the OFSTools.Mount command, the DOS-based file must be copied from its host FAT16 partition to the Oberon partition with DOS.Copy .
E.g. DOS.Copy c:/system3/native.dsk => native.dsk ~
This Mount command variant makes it possible to exploit legacy data in former DOS-based Oberon systems.
Accessing a FAT16 partition
Instead of mounting a DosBasedFS, one can exchange files between Oberon and a FAT16 file system using the DOS command collection documented in DOS.Tool, an external medium by means of Backup commands or a server accessed by ftp. Solved differently in the alpha version.
File backup to a FAT16 partition
A batch of files is written from one partition to another using DOS.CopyTo, and is restored to the partition using DOS.CopyFrom. DOS.Tool provides the details.
The same result can be achieved by executing DOS.Copy commands at the cost of more editing of the filenames. There are numerous cases where a DOS.Copy command is even required. Executing a DOS.Directory command directed to a FAT partition, shows a plethora of "~" embedded in filenames, names which are then obviously invalid as destination filename in Oberon, as in this example:
DOS.CopyFrom "E:/ofwmay/work/" "mailsi~1.tex" ~
but this works:
DOS.Copy "E:/ofwmay/work/mailsi~1.tex" => Mail.Sig.Text ~
File backup to a diskette
Files are copied from a partition to a diskette using Backup.WriteFiles, and are restored to the partition using Backup.ReadFiles. Backup.Tool provides the details. For doing that, a diskette does not need mounting. Filenames are limited to the 8+3 format.
A Backup diskette cannot be mounted. The Backup tool format is not compatible with either NatFS or AosFS.
[WG92] Niklaus Wirth and Jürg Gutknecht - Project Oberon - The Design of an Operating System and Compiler - Addison-Wesley, 1992.
5 Nov 2002 - Copyright © 2002 ETH Zürich. All rights reserved.