If you use two or more operating systems you probably will want to exchange data between them at some point. If they are on separate computers and the computers are networked, you can use programs like ftp(1) (available for most, if not all, operating systems) or (between Unix-like systems) rcp(1). Between non-networked computers you can use kermit(1) (also available for most, if not all, operating systems) to transfer data via modem or over a serial line connection.
The above may also apply when you are running two or more operating systems at the same time on a single computer using a virtual or emulated machine such as provided by VMWare, VirtualPC, Bochs, or Qemu. It may be possible for a guest OS and its host OS or another guest OS to connect via a network as if they were running on completely separate computers. It may also be possible for two such systems to read each other's disks, as described in the next paragraph.
Exchange of data between different operating systems running at different times on the same computer or on two computers that can't communicate by wire requires arranging for one system or the other to read and write "foreign" floppy disks or hard disk partitions. With floppy disks the only problem is to interpret the data structures used by the foreign file system. With hard disk partitions there may be another problem to be solved first: although all operating systems that use the same hardware platform must use the method of defining primary disk partitions that is supported by the system's ROM boot code, operating system designers have devised various ways of further dividing primary partitions into subpartitions. This document deals with the problem of interpreting foreign file systems; see the file on partition compatibility for information on the subpartition problem.
Minix 3 was released in late 2005 and is described in the 3rd edition of the text by Tanenbaum and Woodhull, Operating Systems Design and Implementation, published in early 2006. Minix 3 has many changes, including a new version of the Minix file system. Unlike the Minix 2 file system, which was also capable of reading Minix 1 file systems, the Minix 3 file system is not able to read Minix 2 file systems. As this is written (June 2006) nobody has announced any kind of utility programs to copy data between Minix 2 and Minix 3 file systems. This is an obvious topic for a student project, and this situation may be expected to change.
Since Minix is primarily intended for use in teaching, the Minix 3 programmers felt that there would be few Minix 2 installations with large amounts of data that would need to be transferred to new Minix 3 installations. So the goal of keeping Minix simple trumped making Minix useful in this case. If you happen to have a large amount of data on a Minix 2 machine you will curse this decison, of course. This website is one such installation; the owner found setting up Minix 2 and Minix 3 systems on separate computers and transferring files on the local network was the easiest way to deal with this.
Another consequence of the change from the Minix 2 to the Minix 3 file system is that support that may have existed in other systems for reading Minix files may no longer work. See the section below on accessing Linux acccess to Minix file systems.
The primary purpose of Minix is to illustrate operating system principles. Keeping Minix small enough to fit into a student's head during a semester- or year-long course has required keeping it simple. In particular, the Minix file system supports mounting only media containing Minix file systems.
In the Unix world mounting a file system has a definite meaning: a mounted file system is part of a single directory tree with / at its root. But just because Minix cannot mount foreign file systems doesn't mean they can't be accessed. The standard Minix distribution contains utility programs to allow reading and writing files and directories in MS-DOS and Windows file systems, and for reading files and directories in ISO-9660 file systems, as found on CD-ROMs. These programs are the dos* utilities, mtools, and the iso* utilities.
Accessing MS/DOS and Windows file systems from Minix:
The old way (before Minix 2.0.3) is the Minix dosdir(1), dosread(1), and doswrite(1) utilities. These can handle floppy disks and relatively small FAT partitions.
These commands work only with relatively small FAT file systems. How small? Early versions were intended for use only with floppy disks, but the current version can handle partitions of up to 256 MB. An article on file, file system, and memory size limits in Minix provides more information. If your native Windows file system can't be handled by the dos* tools because it is too big or is an NTFS (Windows 2K, XP default) file system, one way around the problem is make an extra small Windows FAT partition that the Minix tools can handle to use as a staging area for files to be transferred between the OSs.
The new way is the mtools command. Unfortunately, as of the Minix 2.0.3 release there is no man page for mtools. However, use is simple. Mtools takes as its first argument a standard DOS command line command, such as copy, dir, etc. Additional arguments are DOS and Minix paths. The Minix path is expressed in standard Minix syntax. The DOS path is expressed with the Minix device, a colon (':'), and the path with Unix type forward-slash separators. For example:
# mtools copy /dev/fd0:/dir1/file1.txt /usr/local/docs
Mtools contains its own help facility, type "mtools -?". Mtools does have a downside, it is greedy for memory. By default it is chmem-ed to use more than 10 Mbytes. But most systems with disk partitions too large for the dosread family of utilities have lots of memory.
Also, see the article on using DOSMinix as a bridge between Minix and Windows.
Analogous to the dos* commands, a set of isoinfo(1), isodir(1), and isoread(1) commands exist for accessing ISO-9660 (CD-ROM) files from Minix:
Of course, to use the iso* tools you need to know the Minix device that corresponds to your CD-ROM. It will most like be /dev/c0d1 or /dev/c0d2 on a typical computer with one hard drive and one CD-ROM drive. (That's for Minix 2.0.3 or later, for earlier versions try /dev/hd5 or /dev/hd10). You can use the part command or experiment with isoinfo with different arguments to identify the CD-ROM drive.
Accessing files in Linux ext2 file systems from Minix:
Terry McConnell ported a package called ext2tools, originally written for MS-DOS, to Minix. As originally written by Claus Tondering, this package provided tools for accessing a Linux ext2 filesystem from MS-DOS. The port provides the same functionality for accessing Linux files from Minix. The following programs are included:
Of course, as of 2003 Linux has moved on, and ext2 is no longer the most widely used Linux file system. One way to deal with this is similar to what was suggested above for Windows: make an extra Linux partition that uses ext2, or perhaps even the Linux minix file system, and use this as a staging point for files to be transferred.
Terry McConnell has extended a package originally called MinDOS to make mintools, which gives access to Minix files from an MS-DOS prompt.
This category is a no-brainer for Minix 2. Linus used the then-current Minix file system as the basis for Linux , and although Linux hard drives usually use the Linux ext3 or another newer file system now, support for the Minix file system is usually included if floppy disk access is required -- newer file systems are not suited for floppy disks, and the Minix fs is used for floppy disks by default. Just be sure when you configure Linux that you include support for the Minix file system.
It is particularly ironic that Linux, which originally used the Minix file system and has always supported it can not read Minix 3 partitions or floppy disks. As of June 2006 the only solution is patches for various Linux versions that have been written and posted by the author at http://www.terra.es/personal2/danarag/, These have not yet been merged into standard Linux distributions.
With a virtual or emulated host platform, as provided by Bochs or VMWare, one frequently needs to transfer data from the host OS to the guest OS or vice versa. Depending on the capabilities of the two systems, there may be several ways to do this.
Network connection: If both the host and the guest are network-capable, then file transfers are easy. With Minix on Bochs on a Windows host the host can use ftp to get and put files into the file space of the Minix guest. Bochs presents an emulated NE2000 ethernet interface to its guest operating systems. A network connection between guest and host will also work with Minix on VMWare on Windows. Minix support for the AMD Lance ethernet card emulation presented by VMWare to a guest OS was not part of the standard Minix 2.0.4 distribution, but is now available here: /pub/contrib/204ether.tar.Z. It is also precompiled into the Minix 2.0.4 Virtual Machine for VMWare Player, available at /pub/demos-2.0/VMWarePlayer.
If a direct network connection between the guest and the host isn't possible, transfer of files through the file space of another machine on the network might be the easiest way.
Floppy disks: If the guest OS can write to physical floppy disks, these can be used to transfer files. Minix can use mtools or the dosread and doswrite programs to access an MS-DOS formatted floppy disk. From the Windows host side mintools can be used to access Minix disks. For files too big to fit on a floppy disk the fdvol utility provided in the dosutils directory on Minix download sites can be used on the Windows host side to write to multiple disks that the Minix guest can read with the vol command. From the Minix side dd can be used to break a large file into smaller chunks that doswrite or mtools can write to MS-DOS floppy disks, and on the Windows side the MS-DOS copy command can be used to concatenate smaller files to a larger file.
Virtual disks: With Bochs on Windows 98 access to physical floppy disks from a guest OS is not supported, so only files used as virtual disks can be read and written by the guest OS. But in many cases virtual disks are easier to use than physical floppy disks anyway, especially since access to floppy disks from Bochs is very slow. Fortunately, unlike a virtual hard disk, new virtual floppy disks can be created while running Bochs, and multiple virtual floppy disks can be accessed during a single session. Also, mtools can be used to format a virtual floppy disk with an MS-DOS FAT file system, and on the Windows side there is a free program, DiskExplorer, that can transfer files back and forth between the virtual disk and the Windows host file system.
Things unknown ... As I update this section most of my own experience with virtual and emulated systems still has been only with VMWare and Bochs on Windows. I would like to add to this section more information about file transfers between Minix guest systems and Linux, Unix, and Mac OS hosts. I'd also like to hear about use of other virtual or emulated systems -- Qemu, Xen, Virtual PC and others should be useful. Information from readers would be appreciated.
|[HOME]||[HINTS/FAQ]||[MINIX DOWNLOADS]||[CONTRIB SOFTWARE]|