![[Previous]](prev.gif) |
![[Contents]](contents.gif) |
![[Index]](keyword_index.gif) |
![[Next]](next.gif) |
|
|
|
|
This chapter covers the following topics:
Each filesystem has its own root directory. This root is at the top of the directory hierarchy and is where QNX starts looking for other directories and files. The typical name for the root directory of the default filesystem on a hard disk is slash (/).
A filesystem rooted at / may be composed of one or more physical filesystems grafted together. A physical filesystem can be a separate disk or partition.
If a hard disk has more than one filesystem, their names might be /hd2, /hd3, /home2, /home3, etc.
One of the physical filesystems is typically assigned to be the root (/), while the other filesystems are mounted as subdirectories.
A prefix tree maps pathnames to I/O managers and determines which disks and devices are accessed when a process opens a file. In all the examples in this chapter, the prefix tree is used to partition the namespace. For more information about the prefix tree, see the I/O Namespace chapter in System Architecture.
The mount utility can be used to mount disk partitions as block special files, and to mount block special files as QNX filesystems. When you mount a block special file as a filesystem, its location in the pathname space is called a mount point.
For example, given a QNX partition (type 77) on hard disk 0 (/dev/hd0), the following command would create the block special file /dev/hd0t77:
mount -p /dev/hd0
The following command would mount all partitions found on hard disk 0 and mount the QNX partition as the root:
mount -p /dev/hd0 /dev/hd0t77 /
 |
The superuser, the owner, or anyone who has write permission to a device (e.g. disk) or partition can mount or unmount that device. For example, it's a good idea to unmount floppy devices or other removable media before removing the disk from the drive. This will help prevent unusual errors or possible file corruption. For more information, see the description of umount in the Utilities Reference. |
The examples that follow should help clarify how the pathname space is partitioned. We'll look at these configurations:
In these examples, we assume that Fsys as well as the appropriate drivers are running, and that the mount -p command has been done on your hard disk.
The hard disk is mounted as slash (/) and forms the root of the filesystem. The floppy is mounted as /fd0:
mount /dev/hd0t77 / mount /dev/fd0 /fd0
Any reference to a pathname starting with /fd0 will be directed to a QNX filesystem on the floppy. For example, to show all files on the floppy:
ls -aR /fd0
The first hard disk is mounted as slash (/) and forms the root of the filesystem. The second hard disk is mounted as /home2:
mount /dev/hd0t77 / mount /dev/hd1t77 /home2
Any reference to a pathname starting with /home2 will be directed to a QNX filesystem on the second hard drive. For example, to show all files on the second hard drive:
ls -aR /home2
You can have up to four QNX partitions on a single hard drive. The primary partition should be type 77 (see the fdisk utility in the Utilities Reference). The rest should be assigned 78, 79, and 80. For example:
mount /dev/hd0t77 / mount /dev/hd0t78 /home2
Any reference to a pathname starting with /home2 will be directed to a QNX filesystem on the second partition. For example, to show all files on the second partition:
ls -aR /home2
In a network, you might have disks with QNX filesystems on more than one machine. You may configure the namespace for these filesystems to be:
In the following examples, you'll notice that local filesystems are associated with block special files (e.g. /dev/hd0t77), while remote filesystems are associated with pathname prefix mappings. This prefix mapping redirects requests to a remote filesystem that will be associated with a remote block special file.
In this configuration, you treat each machine as an independent, self-contained filesystem. To access a file on a remote machine, you'd precede a pathname with the remote machine's node number. For example:
//10/etc/motd
The ability to specify a filesystem for a particular node will always work and is the most general mechanism for accessing remote files.
In this configuration, you treat one filesystem as the primary and you mount the second filesystem as a subdirectory under the primary. For example, assume node 1 has the primary and node 2 has the secondary mounted as /home2. Node 1 boots from hard disk and has its root set to its local disk by a mount utility built into the OS image (with Fsys and a driver). Its system initialization file would invoke the prefix utility to mount the remote filesystem as follows:
prefix -A /home2=//2/home2
Node 2 boots over the network from node 1 and has its filesystem root set to /=//1/ using the -r option of the sinit utility built into the OS. Its system initialization file would invoke the mount utility to mount the local filesystem as follows:
mount /dev/hd0t77 /home2
The Filesystem Manager (Fsys) and its driver may be built into the image, but they're more likely started from the system initialization file. In other words, node 2 boots like a simple diskless machine, then starts its filesystem after booting.
Both nodes 1 and 2 will access the filesystem on node 1 as / and the filesystem on node 2 as /home2.
In this configuration, you treat each machine as an independent self-contained filesystem, but you link portions of them together via the prefix utility. For example, assume that the filesystem on node 1 has a /home1 directory while the filesystem on node 2 has a /home2 directory. You could map each home directory into the other filesystem's space as follows:
On node 1:
prefix -A /home2=//2/home2
On node 2:
prefix -A /home1=//1/home1
Other than this link, each filesystem is self-contained with its own copies of /bin etc. The advantage is greater redundancy: if one department uses node 2, and node 1 goes down, the department using node 2 can continue to work (except that the files under /home1 won't be available).
Alternatively, you could use symbolic links to access files in another filesystem. A symbolic link creates a special file that has a pathname as its data. To create a symbolic link, specify the -s option to the ln utility.
Let's say there's a file called file1 in the /home1 directory on node 1. The following command would let the department using node 2 access file1 through the file2 symbolic link in the /home2 directory:
ln -s /home1/file1 //2/home2/file2
This creates the symbolic link //2/home2/file2, which points to /home1/file1. You could display the contents of file1 within the /home2 directory on node 2 using the less utility as follows:
less file2
For more information about symbolic links, see the Filesystem Manager chapter in System Architecture.
The superuser can delete (typically via the rm utility) block special devices. If all the devices that a driver is responsible for are deleted, the driver will terminate automatically. This allows users with the appropriate privileges to install, remove, and reinstall drivers in a running system.
|
For information about how to change user permissions, see the "File permissions" section in the chapter on Setting up User Accounts. |
The Dosfsys filesystem manager provides access to DOS files and directories that reside on DOS disks or partitions. Dosfsys can support up to eight drives.
You can create, read, write, and delete files and directories on DOS disks with most QNX programs and standard QNX utilities (such as mkdir, ls, and rmdir). Most QNX utilities will work with DOS files, provided the DOS file structure allows for the functionality required by the utility.
Your own C programs will also be able to process DOS files just as they process QNX files, by using the standard I/O functions such as open(), read(), write(), close(), seek(), etc. When you read DOS directories, they'll be presented to you in QNX format.
Dosfsys has four invocation modes:
Dosfsys [-S|-s] [-e] [-m] [-t] [dos_drive=qnx_drive[,R]]... & Dosfsys -i [-n node] [dos_drive_path]... Dosfsys -o [-n node] Dosfsys -x [-n node]
The -i option lets you get information about the currently adopted DOS drives. The -o option lets you see the names of any files currently open on each device. The -x option terminates the Dosfsys server.
If you don't specify -i, -o, or -x, Dosfsys will start up and try to adopt the specified drives.
To start or terminate the Dosfsys server, you must be logged in as the superuser (root).
When you start Dosfsys, it:
If no options have been specified, or if either -S or -s has been specified, Dosfsys scans the /dev directory for valid DOS drives to adopt. Unless otherwise specified on the command line, Dosfsys will adopt up to eight drives.
DOS primary partitions (/dev/hd0t1, /dev/hd0t4, /dev/hd0t6, etc.) and extended partitions (/dev/hd0t1.1, /dev/hd0t1.2, etc.) are mounted starting at drive C (/dos/c).
Floppy drives are mounted as follows:
/dev/fd0 --> /dos/a /dev/fd1 --> /dos/b
The Dosfsys filesystem manager can adopt up to eight drives. As mentioned above, Dosfsys will adopt the name /dos as a system prefix. It will also manage each specific drive's name as /dos/a, /dos/b, etc. These names aren't registered in the system prefix tree but are kept internally by Dosfsys. This will be transparent to the user except for the fact that the user won't be able to create files or directories at the /dos root.
A DOS device could be one of the following:
To create an image of a DOS diskette or DOS partition, you use the QNX cp utility. For example, to copy an image of a DOS floppy in your floppy drive 0, you could use the following:
cp /dev/fd0 /usr/qnx/dosa
and then invoke Dosfsys as follows:
Dosfsys a=/usr/qnx/dosa &
The same could be done with a hard disk partition. Dosfsys will handle these images just as it would the actual device.
For all non-removable devices, Dosfsys immediately reads the DOS Boot Parameter Block (BPB) as well as part of the File Allocation Table (FAT) at startup. For removable devices, the BPB and the FAT are read only when the drive is being accessed.
When Dosfsys has a non-removable device open, the device is locked for WRITE so no other process can write to this device without going through Dosfsys. Removable devices are kept open and locked only during accesses (e.g. during reading or writing to the disk). Note that unless you specify the R option, all drives have READ/WRITE access.
The Dosfsys manager supports all DOS partitions formatted with DOS 2.1 or later, including standard primary DOS partitions, DOS large partitions (DOS 4.0 and DOS 5.0 > 32M), and DOS extended partitions (type 5). Hard disks, 51/4" floppies, and 31/2" floppies are supported.
These are the standard DOS hard disk partition types:
| Type: | Description: |
|---|---|
| 1 | DOS primary partition (12-bit FAT) |
| 4 | DOS primary partition (16-bit FAT; <= 32M) |
| 5 | DOS extended partition (DOS 3.3 or later) |
| 6 | DOS primary partition (DOS 4.0 or later; > 32M) |
| 11 | DOS 32-bit FAT; partitions up to 2047G |
| 12 | Same as Type 11, but uses Logical Block Address Int 13h extensions |
| 14 | Same as Type 6, but uses Logical Block Address Int 13h extensions |
| 15 | Same as Type 5, but uses Logical Block Address Int 13h extensions |
DOS uses a structure for text files that's different from the one used in QNX (by text files we mean line-oriented files containing lines of ASCII text separated by line-separator sequences). In DOS, each line of a text file is terminated with a carriage return/linefeed sequence (CR/LF); in QNX each line is terminated by a linefeed character (LF).
The Dosfsys manager doesn't translate these files. All files are treated "as is." Therefore, you may need to use the QNX textto or tr utility to convert your text files before copying them to or from QNX and DOS disks.
Note also that the text files created by some DOS programs may contain a SUB character (^Z) as the last character of the file. This is also treated as is.
Since Dosfsys doesn't translate the contents of files, binary files may be copied to or from the QNX/DOS partitions as is.
In DOS, your filenames are limited to the "8.3" convention (QNX has no such limitation). Also, you can't include any of these characters in a filename (although they're perfectly valid in QNX):
/ \ [ ] : * | + = ; , ?
Nor can you use these filenames:
If you attempt to create a file that contains one of the invalid DOS characters or that has an invalid filename, you'll be denied access.
Since all DOS filenames and filename characters are allowed under QNX, no validation is required on these filenames.
DOS also maps all alphabetical characters to uppercase, so Dosfsys maps these characters to uppercase when creating a DOS filename; it maps a filename to lowercase when returning the filename to a QNX application.
If you specify -t when starting Dosfsys, the server will translate and/or truncate any QNX filenames that don't conform to the DOS naming conventions. The following table describes how names are translated:
| If the QNX filename: | Dosfsys will: |
|---|---|
| starts with a dot (.) | change the . to a $ |
| contains multiple dots | change all but the last dot to a $ |
| has a prefix longer than eight characters | truncate the prefix to eight characters |
| has a suffix longer than three characters | truncate the suffix to three characters |
|
The Microsoft Windows 95 release has added support for long filenames that aren't limited to the traditional DOS 8.3 filename convention. Dosfsys can read, but not create, long Windows 95 filenames. To have Dosfsys recognize long Windows 95 filenames, specify the -L option when starting Dosfsys. |
Here are some examples:
| QNX filename: | DOS filename: |
|---|---|
| .profile | $profile |
| a.b.c.d | a$b$c.d |
| longfilename | longfile |
| longfilename.extension | longfile.ext |
| a..b..c.def.g.h | a$$b$$c$.h |
DOS uses the concept of a volume label, which is an actual directory entry at the root of a DOS filesystem. To distinguish between the volume label and an actual DOS file, Dosfsys places an equal sign (=) as the first character of the volume label name. Dosfsys treats this directory entry as a zero-length, read-only file whose permissions cannot be changed.
DOS doesn't support all of the permission bits that QNX does. The DOS attribute bits are as follows:
Dosfsys uses the following mapping logic to handle the QNX-to-DOS attribute-bit translations:
The following mapping logic is used to handle the DOS-to-QNX permission-bit translations:
|
If a file is written to, the DOS ARCHIVE bit will be set.
If Dosfsys is started with the -e option, all DOS files and directories will have the QNX EXECUTE bits set for group/owner/other. |
Although the DOS filesystem doesn't support user IDs and group IDs, Dosfsys will not return an error code if an attempt is made to change the group ID or user ID with the chown utility or chown() library function. An error isn't returned because a number of utilities make use of the chown() library function, which could result in many error messages being displayed.
All files under Dosfsys are owned by the superuser (uid=0, group=0) with access to all.
The -x option terminates the Dosfsys server. If you specify -x, no new open() requests will be accepted and the server will terminate once all active files (i.e. files still open) are closed.
If a request made to Dosfsys isn't supported, the EOPNOTSUPP error code will be returned to the application making the request. Examples of requests not supported by Dosfsys include:
If Dosfsys detects a corrupt filesystem, it will return EBADFSYS, at which point you may wish to run the CHKDSK utility under DOS to correct the problem.
The DOS filesystem structure is such that the root directory's size is fixed at format time and cannot be resized. If it does become full, an error will be returned (ENOSPC).
|
|
|
|