Mercurial > hg > Members > kono > nitros9-code
annotate docs/nitros9guide/chap3.chapter @ 363:647e56c744cf
Added deiniz.refentry error.refentry park.refentry mainly as placeholders
since I don't have the actual documentation.
| author | roug |
|---|---|
| date | Sat, 03 Aug 2002 17:01:11 +0000 |
| parents | bb3e4d64103a |
| children | 41e412b40024 |
| rev | line source |
|---|---|
| 144 | 1 <chapter> |
| 2 <title>The OS-9 File System</title> | |
| 3 <section> | |
| 4 <title>Introduction to the Unified Input/Output System</title> | |
| 5 <para> | |
| 6 OS-9 has a unified input/output system in which data transfers to | |
| 7 ALL I/O devices are performed in almost exactly the same manner, | |
| 8 regardless of the particular hardware devices involved. It may seem | |
| 9 that the different operational characteristics of the I/O devices | |
| 10 might make this difficult. After all, line printers and disk drives | |
| 11 behave much differently. However, these differences can mostly be | |
| 12 overcome by defining a set of standardized | |
| 13 <emphasis>logical functions</emphasis> for | |
| 14 all devices and by making all I/O devices conform to these | |
| 15 conventions, using software routines to eliminate hardware | |
| 16 dependencies wherever possible. This produces a much simpler and | |
| 17 more versatile input/output system. | |
| 18 </para> | |
| 19 <para> | |
| 20 OS-9's unified I/O system is based upon logical entities called | |
| 21 "I/O paths". Paths are analogous to "software I/O channels" which | |
| 22 can be routed from a program to a mass-storage file, any other I/O | |
| 23 device, or even another program. Another way to say the same thing | |
| 24 is that paths are files, and all I/O devices behave as files. | |
| 25 </para> | |
| 26 <para> | |
| 27 Data transferred through paths may be processed by OS-9 to | |
| 28 conform to the hardware requirements of the specific I/O device | |
| 29 involved. Data transfers can be either bidirectional (read/write) | |
| 30 or unidirectional (read only or write only), depending on the device | |
| 31 and/or how the path was established. | |
| 32 </para> | |
| 33 <para> | |
| 34 Data transferred through a path is considered to be a stream of | |
| 35 8-bit binary bytes that have no specific type or value: what the | |
| 36 data actually represents depends on how it is used by each program. | |
| 37 This is important because it means that OS-9 does not require data | |
| 38 to have any special format or meaning. | |
| 39 </para> | |
| 40 <para> | |
| 41 Some of the advantages of the unified I/O system are: | |
| 42 </para> | |
| 43 <itemizedlist mark="square"> | |
| 44 <listitem><para> | |
| 45 Programs will operate correctly regardless of the particular I/O | |
| 46 devices selected and used when the program is actually executed. | |
| 47 </para></listitem> | |
| 48 <listitem><para> | |
| 49 Programs are highly portable from one computer to another, even | |
| 50 when the computers have different kinds of I/O devices. | |
| 51 </para></listitem> | |
| 52 <listitem><para> | |
| 53 I/O can be redirected to alternate files or devices when the | |
| 54 program is run, without having to alter the program. | |
| 55 </para></listitem> | |
| 56 <listitem><para> | |
| 57 New or special device driver routines can easily be created and | |
| 58 installed by the user. | |
| 59 </para></listitem> | |
| 60 </itemizedlist> | |
| 61 </section> | |
| 62 | |
| 63 <section> | |
| 64 <title>Pathlists: How Paths Are Named</title> | |
| 65 <para> | |
| 66 Whenever a path is established (or "opened"), OS-9 must be given | |
| 67 a description of the "routing" of the path. This description is | |
| 68 given in the form of a character string called a "pathlist". It | |
| 69 specifies a particular mass-storage file, directory file, or any | |
| 70 other I/O device. OS-9 "pathlists" are | |
| 71 similar to "filenames" used | |
| 72 by other operating systems. | |
| 73 </para> | |
| 74 <para> | |
| 75 The name "pathlist" is used instead | |
| 76 of "pathname" or "filename" | |
| 77 because in many cases it is a list consisting of more than one name | |
| 78 to specify a particular I/O device or file. In order to convey all | |
| 79 the information required, a pathlist may include a device name, one | |
| 80 or more directory file names and a data file name. Each name within | |
| 81 a pathlist is separated by slash "/" characters. | |
| 82 </para> | |
| 83 <para> | |
| 84 Names are used to describe three kinds of things: | |
| 85 | |
| 86 <itemizedlist> | |
| 87 <listitem><para>Names of Physical I/O Devices</para></listitem> | |
| 88 <listitem><para>Names of Regular Files</para></listitem> | |
| 89 <listitem><para>Names of Directory Files</para></listitem> | |
| 90 </itemizedlist> | |
| 91 | |
| 92 | |
| 93 Names can have one to 29 characters, all of which are used for | |
| 94 matching. They must becin with an upper- or lower-case letter | |
| 95 followed by any combination of the following characters: | |
| 96 </para> | |
| 97 | |
| 98 <simplelist> | |
| 99 <member>uppercase letters: A - Z</member> | |
| 100 <member>lowercase letters: a - z</member> | |
| 101 <member>decimal digits: 0 - 9</member> | |
| 102 <member>underscore: _</member> | |
| 103 <member>period: .</member> | |
| 104 </simplelist> | |
| 105 | |
| 106 <para> | |
| 107 Here are examples of <emphasis>legal</emphasis> names: | |
| 108 <informaltable frame="none"> | |
| 109 <tgroup cols="2"> | |
| 110 <colspec colwidth="2.5in"> | |
| 111 <colspec colwidth="2.5in"> | |
| 112 <tbody> | |
| 113 <row> | |
| 114 <entry>raw.data.2</entry> | |
| 115 <entry>projectreview.backup</entry> | |
| 116 </row> | |
| 117 <row> | |
| 118 <entry>reconciliation.report</entry> | |
| 119 <entry>X042953</entry> | |
| 120 </row> | |
| 121 <row> | |
| 122 <entry>RJJones</entry> | |
| 123 <entry>search.bin</entry> | |
| 124 </row> | |
| 125 </tbody> | |
| 126 </tgroup> | |
| 127 </informaltable> | |
| 128 | |
| 129 Here are examples of <emphasis>illegal</emphasis> names: | |
| 130 | |
| 131 <informaltable frame="none"> | |
| 132 <tgroup cols="2"> | |
| 133 <colspec colwidth="3.1in"> | |
| 134 <colspec colwidth="2.0in"> | |
| 135 <tbody> | |
| 136 <row> | |
| 137 <entry>22November</entry> | |
| 138 <entry>(does not start with a letter)</entry> | |
| 139 </row> | |
| 140 <row> | |
| 141 <entry>max*min</entry> | |
| 142 <entry>(* is not a legal character)</entry> | |
| 143 </row> | |
| 144 <row> | |
| 145 <entry>.data</entry> | |
| 146 <entry>(does not start with a letter)</entry> | |
| 147 </row> | |
| 148 <row> | |
| 149 <entry>open orders</entry> | |
| 150 <entry>(cannot contain a space)</entry> | |
| 151 </row> | |
| 152 <row> | |
| 153 <entry>this.name.obviously.has.more.than.29.characters</entry> | |
| 154 <entry>(too long)</entry> | |
| 155 </row> | |
| 156 </tbody> | |
| 157 </tgroup> | |
| 158 </informaltable> | |
| 159 </para> | |
| 160 </section> | |
| 161 | |
| 162 <section> | |
| 163 <title>I/O Device Names</title> | |
| 164 <para> | |
| 165 Each physical input/output device supported by the system must | |
| 166 have a unique name. The actual names used are defined when the | |
| 167 system is set up and cannot be changed while the system is running. | |
|
149
bb3e4d64103a
Made the word "Dragon" an entity, thereby making it replacable with "Color"
roug
parents:
144
diff
changeset
|
168 The device names used for the &make; Computer are: |
| 144 | 169 </para> |
| 170 <informaltable frame="none"> | |
| 171 <tgroup cols="2"> | |
| 172 <colspec colwidth="0.7in"> | |
| 173 <colspec colwidth="2in"> | |
| 174 <tbody> | |
| 175 <row> | |
| 176 <entry>TERM</entry> | |
| 177 <entry>Video display/keyboard</entry> | |
| 178 </row> | |
| 179 <row> | |
| 180 <entry>P</entry> | |
| 181 <entry>Printer port</entry> | |
| 182 </row> | |
| 183 <row> | |
| 184 <entry>D0</entry> | |
| 185 <entry>Disk drive unit zero</entry> | |
| 186 </row> | |
| 187 <row> | |
| 188 <entry>D1</entry> | |
| 189 <entry>Disk drive unit one</entry> | |
| 190 </row> | |
| 191 <row> | |
| 192 <entry>PIPE</entry> | |
| 193 <entry>Pipes</entry> | |
| 194 </row> | |
| 195 </tbody> | |
| 196 </tgroup> | |
| 197 </informaltable> | |
| 198 <para> | |
| 199 Device names may only be used as the first name of a pathlist, | |
| 200 and must be preceded by a slash "/" character to indicate that the | |
| 201 name is that of an I/O device. If the device is not a disk or | |
| 202 similar device the device name is the only name allowed. This is | |
| 203 true for devices such as terminals, printers, etc. Some examples of | |
| 204 of pathlists that refer to I/O devices are: | |
| 205 </para> | |
| 206 | |
| 207 <simplelist> | |
| 208 <member>/TERM</member> | |
| 209 <member>/P</member> | |
| 210 <member>/D1</member> | |
| 211 </simplelist> | |
| 212 | |
| 213 <para> | |
| 214 I/O device names are actually the names of the "device descriptor | |
| 215 modules" kept by OS-9 in an internal data structure called the | |
| 216 "module directory" (See the OS-9 System Programmer's manual for more | |
| 217 information about device driver and descriptor modules). This | |
| 218 directory is automatically set up during OS-9's system start up | |
| 219 sequence, and updated as modules are added or deleted while the | |
| 220 system is running. | |
| 221 </para> | |
| 222 </section> | |
| 223 | |
| 224 <section> | |
| 225 <title>Multifile Devices And Directory Files</title> | |
| 226 <para> | |
| 227 Multifile devices are mass storage devices (usually disk systems) | |
| 228 that store data organized into separate logical entities called | |
| 229 "files". Each file has a name which is entered in a directory file. | |
| 230 Every multifile device has a master directory (called the "root | |
| 231 directory") that includes the names of the files and sub-directories | |
| 232 stored on the device. The root directory is created automatically | |
| 233 when the disk is initialized by the "format" command. | |
| 234 </para> | |
| 235 <para> | |
| 236 Pathlists that refer to multifile devices may have more than one | |
| 237 name. For example, to refer to the file "mouse" whose name appears | |
| 238 in the root directory of device "D1" (disk drive one) the following | |
| 239 pathlist is used: | |
| 240 </para> | |
| 241 <para> | |
| 242 | |
| 243 /d1/mouse | |
| 244 | |
| 245 </para> | |
| 246 <para> | |
| 247 When OS-9 is asked to create a path, it uses the names in the | |
| 248 pathlist sequentially from left to right to search various | |
| 249 directories to obtain the necessary routing information. These | |
| 250 directories are organized as a tree-structured hierarchy. The | |
| 251 highest-level directory is called the "device directory", which | |
| 252 contains names and linkages to all the I/O devices on a given | |
| 253 system. If any of the devices are of a multifile type they each | |
| 254 have a root directory, which is the next-highest level. | |
| 255 </para> | |
| 256 <para> | |
| 257 The diagram below is a simplified file system tree of a typical | |
| 258 OS-9 system disk. Note that device and directory names are capitalized | |
| 259 and ordinary file names are not. This is a customary (but | |
| 260 not mandatory) practice which allows you to easily identify directory | |
| 261 files using the short form of the "dir" command. | |
| 262 </para> | |
| 263 <literallayout class="Monospaced"> | |
| 264 System Device Directory | |
| 265 +---------------------------------+ | |
| 266 ! ! ! ! | |
| 267 D0 TERM P D1 | |
| 268 ! ! | |
| 269 ! ! | |
| 270 ! ! | |
| 271 D0 Root Directory D1 Root Directory | |
| 272 +----------------------+ +----------------------+ | |
| 273 ! ! ! ! ! ! | |
| 274 DEFS startup CMDS file1 file2 file3 | |
| 275 ! ! | |
| 276 ! ! | |
| 277 ! ! | |
| 278 --+-- +-----+----+-----+-----+ | |
| 279 ! ! ! ! ! ! | |
| 280 OS9Defs copy list dir del backup | |
| 281 </literallayout> | |
| 282 <para> | |
| 283 The device names in this example system are "TERM", | |
| 284 "P", "D0" and | |
| 285 "D1". The root directory of device | |
| 286 "D0" includes two directory | |
| 287 files, DEFS and CMDS, and one ordinary file "startup". Notice that | |
| 288 device "D1" has in its root directory three ordinary files. In | |
| 289 order to access the file "file2" on | |
| 290 device "d1", a pathlist having | |
| 291 two names must be used: | |
| 292 <screen> | |
| 293 list /d1/file2 | |
| 294 </screen> | |
| 295 To construct a pathlist to access the file "dir" on device | |
| 296 "d0" it is necessary to include in the pathlist the name of the | |
| 297 intermediate directory file "CMDS". For example, to copy this file | |
| 298 requires a pathlist having three names to describe the "from" file: | |
| 299 <screen> | |
| 300 copy /d0/cmds/dir temp | |
| 301 </screen> | |
| 302 </para> | |
| 303 </section> | |
| 304 | |
| 305 <section> | |
| 306 <title>Creating and Using Directories</title> | |
| 307 <para> | |
| 308 It is possible to create a virtually unlimited number of levels | |
| 309 of directories on a mass storage device using the "makdir" command. | |
| 310 Directories are a special type of file (see 3.8.1). They can be | |
| 311 processed by the same I/O functions used to access regular files | |
| 312 which makes directory-related processing fairly simple. | |
| 313 </para> | |
| 314 <para> | |
| 315 To demonstrate how directories work, assume that the disk in | |
| 316 drive one ("d1") has been freshly formatted so that it has a root | |
| 317 directory only. The build command can be used to create a text file | |
| 318 on "d1". The build command will print out "?" as a prompt to | |
| 319 indicate that it is waiting for a text line to be entered. It will | |
| 320 place each line into the text file until an empty line with only a | |
| 321 carriage return is entered, as shown below: | |
| 322 </para> | |
| 323 <screen> | |
| 324 OS9: build /d1/file1 | |
| 325 ? This is the first file that | |
| 326 ? we created. | |
| 327 ? [ENTER] | |
| 328 </screen> | |
| 329 | |
| 330 <para> | |
| 331 The "dir" command will now indicate the existence of the new file: | |
| 332 </para> | |
| 333 | |
| 334 <screen> | |
| 335 OS9: dir /d1 | |
| 336 | |
| 337 Directory of /d1 15:45:29 | |
| 338 file1 | |
| 339 </screen> | |
| 340 | |
| 341 <para> | |
| 342 The "list" command can be used to display the text stored in the | |
| 343 file: | |
| 344 </para> | |
| 345 | |
| 346 <screen> | |
| 347 OS9: list /d1/file1 | |
| 348 | |
| 349 This is the first file | |
| 350 that we created. | |
| 351 </screen> | |
| 352 | |
| 353 <para> | |
| 354 The "build" command again is again used to create two more text | |
| 355 files: | |
| 356 </para> | |
| 357 | |
| 358 <screen> | |
| 359 OS9: build /d1/file2 | |
| 360 ? This is the second file | |
| 361 ? that we created. | |
| 362 ? [ENTER] | |
| 363 | |
| 364 OS9: build /d1/file3 | |
| 365 ? This is another file. | |
| 366 ? [ENTER] | |
| 367 </screen> | |
| 368 | |
| 369 <para> | |
| 370 The dir command will now show three file names: | |
| 371 </para> | |
| 372 | |
| 373 <screen> | |
| 374 OS9: dir /d1 | |
| 375 Directory of /D1 15:52:29 | |
| 376 file1 file2 file3 | |
| 377 </screen> | |
| 378 | |
| 379 <para> | |
| 380 To make a new directory in this directory, the "makdir" command is | |
| 381 used. The new directory will be called "NEWDIR". Notice that | |
| 382 throughout this manual directory names are always capitalized. This | |
| 383 is <emphasis>not</emphasis> a requirement of OS-9 (see 3.1) . Rather, it is a | |
| 384 practice popular with many OS-9 users because it allows easy identification | |
| 385 of directory files at all times (assuming all other file names use | |
| 386 lower-case letters). | |
| 387 </para> | |
| 388 | |
| 389 <screen> | |
| 390 OS9: makdir /D1/NEWDIR | |
| 391 </screen> | |
| 392 | |
| 393 <para> | |
| 394 The directory file "NEWDIR" is now a file listed in D1's root | |
| 395 directory: | |
| 396 </para> | |
| 397 | |
| 398 <screen> | |
| 399 OS9: dir /D1 | |
| 400 | |
| 401 Directory of /D1 16:04:31 | |
| 402 file1 file2 file3 NEWDIR | |
| 403 </screen> | |
| 404 | |
| 405 <para> | |
| 406 Now we will create a new file and put in the new directory, using | |
| 407 the COPY command to duplicate "file1": | |
| 408 </para> | |
| 409 <screen> | |
| 410 OS9: COPY /D1/file1 /D1/NEWDIR/file1.copy | |
| 411 </screen> | |
| 412 <para> | |
| 413 Observe that the second pathlist now has three names: the name of | |
| 414 the root directory ("D1"), the name of the next lower directory | |
| 415 ("NEWDIR"), then the actual file name ("file1.copy"). Here's what | |
| 416 the directories look like now: | |
| 417 </para> | |
| 418 <screen> | |
| 419 D1 Root Directory | |
| 420 +---------+--------+--------+ | |
| 421 ! ! ! ! | |
| 422 NEWDIR file1 file2 file3 | |
| 423 ! | |
| 424 ! | |
| 425 file1.copy | |
| 426 </screen> | |
| 427 <para> | |
| 428 The dir command can now show the files in the new directory: | |
| 429 </para> | |
| 430 <screen> | |
| 431 OS9: dir /D1/NEWDIR | |
| 432 | |
| 433 Directory of /D1/NEWDIR | |
| 434 file1.copy | |
| 435 </screen> | |
| 436 <para> | |
| 437 It is possible to use "makdir" to create additional new directories | |
| 438 within "NEWDIR", and so on, limited only by available disk | |
| 439 space. | |
| 440 </para> | |
| 441 </section> | |
| 442 | |
| 443 <section> | |
| 444 <title>Deleting Directory Files</title> | |
| 445 <para> | |
| 446 The "del" command cannot be used to directly delete a directory | |
| 447 file. If a directory file that still contained file names were to | |
| 448 be deleted, OS-9 would have no way to access the files or to return | |
| 449 their storage to the unallocated storage pool. Therefore, the | |
| 450 following sequence must be performed to delete a directory file: | |
| 451 </para> | |
| 452 <para> | |
| 453 1 - All file names in the directory must be deleted. | |
| 454 </para> | |
| 455 <para> | |
| 456 2 - The "attr" command is used to turn off the files directory | |
| 457 attrribute (-d option), making it an ordinary file (see 3.8). | |
| 458 </para> | |
| 459 <para> | |
| 460 3 - The file may now be deleted using the "del" command. | |
| 461 </para> | |
| 462 <para> | |
| 463 A simpler alternative is to use the DELDIR command to automatically | |
| 464 perform all these steps for you. | |
| 465 </para> | |
| 466 </section> | |
| 467 | |
| 468 <section> | |
| 469 <title>Additional Information About Directories</title> | |
| 470 <para> | |
| 471 The OS-9 directory system is very useful because it allows each | |
| 472 user to privately organize files as desired (by project, function, | |
| 473 etc.), without affecting other files or other user's files. Another | |
| 474 advantage of the hierarchical directory system is that files with | |
| 475 identical names can be kept on the same device as long as the names | |
| 476 are in different directories. For example, you can have a set of | |
| 477 test files to check out a program using the same file names as the | |
| 478 program's actual working files. You can then run the program with | |
| 479 test data or actual data simply by switching directories. | |
| 480 </para> | |
| 481 <para> | |
| 482 Here are some important characteristics relating to use of directory | |
| 483 files: | |
| 484 </para> | |
| 485 <itemizedlist> | |
| 486 <listitem><para> | |
| 487 Directories have the same ownership and security attributes | |
| 488 and rules as regular files. See Section 3.6. | |
| 489 </para></listitem> | |
| 490 <listitem><para> | |
| 491 The name of a given file appears in exactly one directory. | |
| 492 </para></listitem> | |
| 493 <listitem><para> | |
| 494 Files can only be added to directories when they are created. | |
| 495 </para></listitem> | |
| 496 <listitem><para> | |
| 497 A file and the directory in which its name is kept must reside on | |
| 498 the same device. | |
| 499 </para></listitem> | |
| 500 </itemizedlist> | |
| 501 </section> | |
| 502 | |
| 503 <section> | |
| 504 <title>Using and Changing Working Directories</title> | |
| 505 <para> | |
| 506 Each program (process) has two "working directories" associated | |
| 507 with it at all times: a "data directory" and an "execution | |
| 508 directory". The working directory mechanism allows the name searching | |
| 509 involved in pathlist processing to start at any level (subtree) | |
| 510 of the file system hierarchy. Any directory that the user has | |
| 511 permission to access (see 3.8) can be made a working directory. | |
| 512 </para> | |
| 513 <para> | |
| 514 The rules used to determine whether pathlists refer to the | |
| 515 current working directory or not are simple: | |
| 516 </para> | |
| 517 <para> | |
| 518 ---> When the first character of a pathlist IS a "/", | |
| 519 processing of the pathlist starts at the device directory, | |
| 520 e.g., the first name MUST be a device name. | |
| 521 </para> | |
| 522 <para> | |
| 523 ---> When the first character of a pathlist IS NOT a "/", | |
| 524 processing of the pathlist starts at the current working | |
| 525 directory. | |
| 526 </para> | |
| 527 <para> | |
| 528 Notice that pathlists starting with a "/" | |
| 529 <emphasis>must</emphasis> be complete, in | |
| 530 other words, they must have all names required to trace the pathlist | |
| 531 from the device directory down through all intermediate directories | |
| 532 (if any). For example: | |
| 533 </para> | |
| 534 <informalexample> | |
| 535 <para> | |
| 536 /d2/JOE/WORKINGFILES/testresults | |
| 537 </para> | |
| 538 </informalexample> | |
| 539 <para> | |
| 540 On the other hand, use of the current working directory allows | |
| 541 all names in the file hierarchy tree to be implied instead of | |
| 542 explicitly given. This not only makes pathlists shorter, but allows | |
| 543 OS-9 to locate files faster because (typically) fewer directories | |
| 544 need be searched. For example, if the current working directory is | |
| 545 "/D1/PETE/GAMES" and a pathlist is given such as: | |
| 546 </para> | |
| 547 <para> | |
| 548 baseball | |
| 549 </para> | |
| 550 <para> | |
| 551 the actual pathlist <emphasis>implied</emphasis> is: | |
| 552 </para> | |
| 553 <para> | |
| 554 /D1/PETE/GAMES/baseball | |
| 555 </para> | |
| 556 <para> | |
| 557 Pathlists using working directories can also specify additional | |
| 558 lower-level directories. Referring to the example above, the | |
| 559 pathlist: | |
| 560 </para> | |
| 561 <para> | |
| 562 ACTION/racing | |
| 563 </para> | |
| 564 <para> | |
| 565 implies the complete pathlist: | |
| 566 </para> | |
| 567 <para> | |
| 568 /D1/PETE/GAMES/ACTION/racing | |
| 569 </para> | |
| 570 | |
| 571 <section> | |
| 572 <title>Automatic Selection of Working Directories</title> | |
| 573 <para> | |
| 574 Recall that two working directories are referred to as the | |
| 575 "current execution directory" and the "current data directory". The | |
| 576 reason two working directories are maintained is so that files | |
| 577 containing | |
| 578 <emphasis>programs</emphasis> can be organized in different directories than | |
| 579 files containing <emphasis>data</emphasis>. | |
| 580 OS-9 automatically selects either working | |
| 581 directory, depending on the usage of the pathlist: | |
| 582 </para> | |
| 583 <para> | |
| 584 ---> OS-9 will search the execution directory when it attempts to | |
| 585 load files into memory assumed to be executable programs. This | |
| 586 means that programs to be run as commands or loaded into | |
| 587 memory must be in the current execution directory (See 5.4.1). | |
| 588 </para> | |
| 589 <para> | |
| 590 ---> The data directory is used for all other file references (such | |
| 591 as text files, etc.) | |
| 592 </para> | |
| 593 <para> | |
| 594 Immediately after startup, OS-9 will set the data directory to be | |
| 595 (the root directory of) the system disk drive (usually "D0"), and | |
| 596 the working directory to be a directory called "cmds" on the same | |
| 597 drive ("/D0/cmds"). On timesharing systems, the "login" command | |
| 598 selects the initial execution and data directories to the file names | |
| 599 specified in each user's information record stored in the system | |
| 600 password file(ref. 5.4.2). | |
| 601 </para> | |
| 602 <para> | |
| 603 Here is an example of a shell command statement using the default | |
| 604 working directory notation, and its equivalent expansion: | |
| 605 </para> | |
| 606 <screen> | |
| 607 copy file1 file2 | |
| 608 </screen> | |
| 609 <para> | |
| 610 If the current execution directory is "/D0/CMDS" and the current | |
| 611 data directory is "/D0/JONES", the same command, fully expanded to | |
| 612 show complete pathlists implied is: | |
| 613 </para> | |
| 614 <screen> | |
| 615 OS9: /D0/CMDS/copy /D0/JONES/filel /D0/JONES/file2 | |
| 616 </screen> | |
| 617 <para> | |
| 618 Notice that the first pathlist "copy" expands to the current working | |
| 619 directory pathlist because it is assumed to be an executable program | |
| 620 but the two other file names expand using the data directory because | |
| 621 they are not assumed to be executable. | |
| 622 </para> | |
| 623 </section> | |
| 624 | |
| 625 <section> | |
| 626 <title>Changing Current Working Directories</title> | |
| 627 <para> | |
| 628 The built-in shell commands "chd" and "chx" can be used to | |
| 629 independently change the current working data and execution | |
| 630 directories, respectively. These command names must be followed by | |
| 631 a pathlist that describes the new directory file. You must have | |
| 632 permission to access the directory according to normal file security | |
| 633 rules (See 3.8). Here are some examples: | |
| 634 </para> | |
| 635 <screen> | |
| 636 OS9: chd /D1/MY.DATAFILES | |
| 637 | |
| 638 OS9: chx /D0/TESTPROGRAMS | |
| 639 </screen> | |
| 640 <para> | |
| 641 When using the CHD or CHX commands, pathlists work the same as they | |
| 642 do for regular files, except for the last name in the pathlist must | |
| 643 be a directory name. If the pathlist begins with a "/" , OS-9 will | |
| 644 begin searching in the device directory for the new working | |
| 645 directory, otherwise searching will begin with the present directory | |
| 646 (See 3.6). For example, the following sequence of commands set the | |
| 647 working directory to the same file: | |
| 648 </para> | |
| 649 <screen> | |
| 650 OS9: CHD /D1/SARAH | |
| 651 OS9: CHD PROJECT1 | |
| 652 | |
| 653 OS9: CHD /D1/SARAH/PROJECT1 (same effect as above) | |
| 654 </screen> | |
| 655 </section> | |
| 656 | |
| 657 <section> | |
| 658 <title>Anonymous Directory Names</title> | |
| 659 <para> | |
| 660 Sometimes is useful to be able to refer to the current directory | |
| 661 or the next higher-level directory, but its name (full pathlist) may | |
| 662 not be known. Because of this, special "name substitutes" are | |
| 663 available. They are: | |
| 664 </para> | |
| 665 <para> | |
| 666 "." refers to the present working directory | |
| 667 </para> | |
| 668 <para> | |
| 669 ".." refers to the directory that contains the name of the present | |
| 670 directory (e.g., the next highest level directory) | |
| 671 </para> | |
| 672 <para> | |
| 673 "..." refers to directory two levels up, and so on | |
| 674 </para> | |
| 675 <para> | |
| 676 These can be used in place of pathlists and/or the first name in a | |
| 677 pathlist. Here are some examples: | |
| 678 </para> | |
| 679 <informaltable frame="none"> | |
| 680 <tgroup cols="2"> | |
| 681 <colspec colwidth="1.5in"> | |
| 682 <colspec colwidth="3in"> | |
| 683 <tbody> | |
| 684 <row> | |
| 685 <entry>OS9: dir .</entry> | |
| 686 <entry>lists file names in the working data directory</entry> | |
| 687 </row> | |
| 688 <row> | |
| 689 <entry>OS9: dir ..</entry> | |
| 690 <entry>lists names in the working data directory's parent directory.</entry> | |
| 691 </row> | |
| 692 <row> | |
| 693 <entry>OS9: DEL ../temp</entry> | |
| 694 <entry>deletes the file "temp" from the | |
| 695 working data directory's parent directory.</entry> | |
| 696 </row> | |
| 697 </tbody> | |
| 698 </tgroup> | |
| 699 </informaltable> | |
| 700 <para> | |
| 701 The substitute names refer to either the execution or data | |
| 702 directories, depending on the context in which they are used (See | |
| 703 3.7.1). For example, if ".." is used in a pathlist of a file which | |
| 704 will be loaded and/or executed, it will represent the parent | |
| 705 directory of the execution directory. Likewise, if "." is used in a | |
| 706 pathlist describing a program's input file, it will represent the | |
| 707 current data directory. | |
| 708 </para> | |
| 709 </section> | |
| 710 </section> | |
| 711 | |
| 712 <section> | |
| 713 <title>The File Security System</title> | |
| 714 <para> | |
| 715 Every file (including directory files) has properties called | |
| 716 <emphasis>ownership</emphasis> | |
| 717 and <emphasis>attributes</emphasis> which determine who may access the file and | |
| 718 how it many be used. | |
| 719 </para> | |
| 720 <para> | |
| 721 OS-9 automatically stores with each file the user number | |
| 722 associated with the process that created it. This user is considered | |
| 723 to be the "owner" of the file. | |
| 724 </para> | |
| 725 <para> | |
| 726 Usage and security functions are based on "attributes", which | |
| 727 define how and by whom the file can be accessed. There are a total | |
| 728 of seven attributes, each of which can be turned "off" or | |
| 729 "on" | |
| 730 independently. The "d" attribute is used to indicate (when on) that | |
| 731 the file is a directory file. The other six attributes control | |
| 732 whether the file can be read, written to, or executed, by either the | |
| 733 owner or by the "public" (all other users). Specifically, these six | |
| 734 attributes are: | |
| 735 </para> | |
| 736 <para> | |
| 737 WHITE PERMISSION FOR OWNER: If on, the owner may write to the file | |
| 738 or delete it. This permission can be used to protect important | |
| 739 files from accidental deletion or modification. | |
| 740 </para> | |
| 741 <para> | |
| 742 READ PERMISSION FOR OWNER: If on, the owner is allowed to read | |
| 743 from the file. This can be used to prevent "binary" files from | |
| 744 being used as "text" files (See 3.9) | |
| 745 </para> | |
| 746 <para> | |
| 747 EXECUTE PERMISSION FOR OWNER: If on, the owner can load the file into memory | |
| 748 and execute it. Note that the file <emphasis>must</emphasis> contain one or | |
| 749 more valid OS-9 format memory modules in order to actually load (See | |
| 750 3.9.4 and 5.4.1). | |
| 751 </para> | |
| 752 <para> | |
| 753 The following "public permissions" work the same way as | |
| 754 the "owner permissions" above but are applied to processes having | |
| 755 DIFFERENT user numbers than the file's owner. | |
| 756 </para> | |
| 757 <para> | |
| 758 WRITE PERMISSION FOR PUBLIC - If on, any other user may write to or | |
| 759 delete the file. | |
| 760 </para> | |
| 761 <para> | |
| 762 READ PERMISSION FOR PUBLIC - If on, any other user may read (and | |
| 763 possibly copy) the file. | |
| 764 </para> | |
| 765 <para> | |
| 766 EXECUTE PERMISSION FOR PUBLIC - If on, any other user may execute | |
| 767 the file. | |
| 768 </para> | |
| 769 <para> | |
| 770 For example, if a particular file had all permissions on except | |
| 771 "write permit to public" and "read permit to public", the owner | |
| 772 would have unrestricted access to the file, but other users could | |
| 773 execute it, but not read, copy, delete, or alter it. | |
| 774 </para> | |
| 775 | |
| 776 <section> | |
| 777 <title>Examining and Changing File Attributes</title> | |
| 778 <para> | |
| 779 The "DIR" command may be used to examine the security permissions | |
| 780 of the files in any particular directory when the "e" option is | |
| 781 used. An example using the "dir e" command to show the detailed | |
| 782 attributes of the files in the current working directory is: | |
| 783 </para> | |
| 784 <screen> | |
| 785 Directory of . 10:20:44 | |
| 786 | |
| 787 Owner Last Modified Attributes Sector Bytecount Name | |
| 788 ----- ------------- ---------- ------ --------- ---- | |
| 789 1 81/05/29 1402 --e--e-r 47 42 file1 | |
| 790 0 81/10/12 0215 ---wr-wr 48 43 file2 | |
| 791 3 81/04/29 2335 -s----wr 51 22 file3 | |
| 792 1 82/01/06 1619 d--wr-wr 6D 800 NEWDIR | |
| 793 </screen> | |
| 794 | |
| 795 <para> | |
| 796 This display is fairly self-explanatory. The "attributes" column | |
| 797 shows which attributes are currently on by the presence or absence | |
| 798 of associated characters in the following format: | |
| 799 </para> | |
| 800 <para> | |
| 801 dsewrewr | |
| 802 </para> | |
| 803 | |
| 804 <para> | |
| 805 The character positions correspond to from left to right: directory; | |
| 806 sharable; public execute; public write; public read; owner execute; | |
| 807 owner write; owner read. The "attr" command is used to examine or | |
| 808 change a file's attributes. Typing "attr" followed by a file name | |
| 809 will result in the present attributes to be displayed, for example: | |
| 810 </para> | |
| 811 | |
| 812 <screen> | |
| 813 OS9: attr file2 | |
| 814 -s-wr-ewr | |
| 815 </screen> | |
| 816 | |
| 817 <para> | |
| 818 If the command is used with a list of one or more attribute abbreviations, | |
| 819 the file's attributes will be changed accordingly (if | |
| 820 legal). For example, the command: | |
| 821 </para> | |
| 822 <screen> | |
| 823 OS9: attr file2 pw pr -e -pe | |
| 824 </screen> | |
| 825 <para> | |
| 826 enables public write and public read permissions and removes execute | |
| 827 permission for both the owner and the public. | |
| 828 </para> | |
| 829 <para> | |
| 830 The "directory" attribute behaves somewhat differently than the | |
| 831 read, write, and execute permissions. This is because it would be | |
| 832 quite dangerous to be able to change directory files to normal files | |
| 833 (See 3.5), and creation of a directory requires special initialization | |
| 834 (See 3.4). Therefore, the "attr" command | |
| 835 <emphasis>cannot</emphasis> be used to turn | |
| 836 the directory (d) attribute on (only "makdir" can), and can be used | |
| 837 to turn it off <emphasis>only</emphasis> if the directory is empty. | |
| 838 </para> | |
| 839 </section> | |
| 840 </section> | |
| 841 | |
| 842 <section> | |
| 843 <title>Reading and Writing From Files</title> | |
| 844 <para> | |
| 845 A single file type and format is used for all mass storage files. | |
| 846 Files store an ordered sequence of 8-bit bytes. OS-9 is not usually | |
| 847 sensitive to the contents of files for most functions. A given file | |
| 848 may store a machine language program, characters of text, or almost | |
| 849 anything else. Data is written to and read from files exactly as | |
| 850 given. The file can be any size from zero up to the maximum | |
| 851 capacity of the storage device, and can be expanded or shortened as | |
| 852 desired. | |
| 853 </para> | |
| 854 <para> | |
| 855 When a file is created or opened a "file pointer" is established | |
| 856 for it. Bytes within the file are addressed like memory, and the | |
| 857 file pointer holds the "address" of the next byte in the file to be | |
| 858 written to or read from. The OS-9 "read" and "write" service | |
| 859 functions always update the pointer as data transfers are performed. | |
| 860 Therefore, successive read or write operations will perform sequential data transfers. | |
| 861 </para> | |
| 862 <para> | |
| 863 Any part of a file can also be read or written in non-sequential | |
| 864 order by using a function called "seek" to reposition the file | |
| 865 pointer to any byte address in the file. This is used when random | |
| 866 access of the data is desired. | |
| 867 </para> | |
| 868 <para> | |
| 869 To expand a file, you can simply write past the previous end of | |
| 870 the file. Reading up to the last byte of a file will cause the next | |
| 871 "read" request to return an end-of-file status. | |
| 872 </para> | |
| 873 | |
| 874 <section> | |
| 875 <title>File Usage in OS-9</title> | |
| 876 <para> | |
| 877 Even though there is physically only one type of file, the logical | |
| 878 usage of files in OS-9 covers a broad spectrum. Because all | |
| 879 OS-9 files have the same physical type, commands such as "copy", | |
| 880 "del", etc., can be used with any file regardless of its logical | |
| 881 usage. Similarly, a particular file can be treated as having a | |
| 882 different logical usage at different times by different programs. The | |
| 883 main usage of files covered in this section are: | |
| 884 </para> | |
| 885 <simplelist> | |
| 886 <member>TEXT</member> | |
| 887 <member>RANDOM ACCESS DATA</member> | |
| 888 <member>EXECUTABLE PROGRAM MODULES</member> | |
| 889 <member>DIRECTORIES</member> | |
| 890 <member>MISCELLANEOUS</member> | |
| 891 </simplelist> | |
| 892 </section> | |
| 893 | |
| 894 <section> | |
| 895 <title>Text Files</title> | |
| 896 <para> | |
| 897 These files contain variable-length sequences ("lines") of ASCII | |
| 898 characters. Each line is terminated by a carriage return character. | |
| 899 Text files are used for program source code, procedure files, | |
| 900 messages, documentation, etc. The Text Editor operates on this file | |
| 901 format. | |
| 902 </para> | |
| 903 <para> | |
| 904 Text files are usually read sequentially, and are supported by | |
| 905 almost all high-level languages (such as BASIC09 READ and WRITE | |
| 906 statements). Even though is is possible to randomly access data at | |
| 907 any location within a text file, it is rarely done in practice | |
| 908 because each line is variable length and it is hard to locate the | |
| 909 beginning of each line without actually reading the data to locate | |
| 910 carriage return characters. | |
| 911 </para> | |
| 912 <para> | |
| 913 The content of text files may be examined using the "list" | |
| 914 command. | |
| 915 </para> | |
| 916 </section> | |
| 917 | |
| 918 <section> | |
| 919 <title>Random Access Data Files</title> | |
| 920 <para> | |
| 921 Random-access data files are created and used primarily from | |
| 922 within high-level languages such as Basic09, Pascal, C, and Cobol. | |
| 923 In Basic09 and Pascal, "GET", "PUT", and "SEEK" functions operate on | |
| 924 random-access files. | |
| 925 </para> | |
| 926 <para> | |
| 927 The file is organized as an ordered sequence of "records". Each | |
| 928 record has exactly the same length, so given a record's numerical | |
| 929 index, the record's beginning address within the file can be | |
| 930 computed by multiplying the record number by the number of bytes | |
| 931 used for each record. Thus, records can be directly accessed in any | |
| 932 order. | |
| 933 </para> | |
| 934 <para> | |
| 935 In most cases, the high-level language allows each record to be | |
| 936 subdivided into "fields". Each field generally has a fixed length | |
| 937 and usage for all records within the file. For example, the first | |
| 938 field of a record may be defined as being 25 text characters, the | |
| 939 next field may be two bytes long and used to hold 16-bit binary | |
| 940 numbers, etc. | |
| 941 </para> | |
| 942 <para> | |
| 943 It is important to understand that OS-9 itself does not directly | |
| 944 process or deal with records other than providing the basic file | |
| 945 functions required by all high-level languages to create and use | |
| 946 random-access files. | |
| 947 </para> | |
| 948 </section> | |
| 949 | |
| 950 <section> | |
| 951 <title>Executable Program Module Files</title> | |
| 952 <para> | |
| 953 These files are used to hold program modules generated by the | |
| 954 assembler or <emphasis>compiled</emphasis> by high-level languages. | |
| 955 Each file may | |
| 956 contain <emphasis>one or more</emphasis> program modules. | |
| 957 </para> | |
| 958 <para> | |
| 959 OS-9 program modules resident in memory have a standard module | |
| 960 format that, besides the object code, includes a "module header" and | |
| 961 a CRC check value. Program module(s) stored in files contain exact | |
| 962 binary copies of the programs as they will exist in memory, and not | |
| 963 one byte more (See 5.4.1). OS-9 does not require a "load record" | |
| 964 system commonly used by other operating systems because OS-9 | |
| 965 programs are position-independent code and therefore do not have to | |
| 966 be loaded into specific memory addresses. | |
| 967 </para> | |
| 968 <para> | |
| 969 In order for OS-9 to load the program module(s) from a file, the | |
| 970 file itself must have execute permission (See 3.8) and each module | |
| 971 must have a valid module header and CRC check value. If a program | |
| 972 module has been altered in any way, either as a file or in memory, | |
| 973 its CRC check value will be incorrect And OS-9 will refuse to load | |
| 974 the module. The "verify" command can be used to check the correctness | |
| 975 of the check values, and update them to corrected values if | |
| 976 necessary. | |
| 977 </para> | |
| 978 <para> | |
| 979 On Level One systems, if a file has two or more modules, they are | |
| 980 treated as independent entities after loading and reside at different memory regions. | |
| 981 </para> | |
| 982 <para> | |
| 983 Like other files that contain "binary" data, attempts to "list | |
| 984 program files will result in the display of random characters on the | |
| 985 terminal giving strange effects. The "dump" command can be used to | |
| 986 safely examine the contents of this kind of file in hexadecimal and | |
| 987 controlled ASCII format. | |
| 988 </para> | |
| 989 </section> | |
| 990 | |
| 991 <section> | |
| 992 <title>Directory Files</title> | |
| 993 <para> | |
| 994 Directory files play a key role in the OS-9 file system. | |
| 995 Sections 3.3 through 3.7 of this chapter describe how they are used by | |
| 996 various OS-9 features. | |
| 997 </para> | |
| 998 <para> | |
| 999 Directory files can only be created by the "makdir" command, and | |
| 1000 can be identified by the "d" attribute being set (see 3.8.1). The | |
| 1001 file is organized into 32-byte records. Each record can be a | |
| 1002 directory entry. The first 29 bytes of the record is a string of | |
| 1003 characters which is the file name. The last character of the name | |
| 1004 has its sign bit (most significant bit) set. If the record is not | |
| 1005 in use the first character position will have the value zero. The | |
| 1006 last three bytes of the record is a 24-bit binary number which is | |
| 1007 the logical sector number where the file header record (see 3.10) is | |
| 1008 located. | |
| 1009 </para> | |
| 1010 <para> | |
| 1011 The "makdir" command initializes all records in a new directory | |
| 1012 to be unused entries except for the first two entries. These | |
| 1013 entries have the names "." and ".." along with the logical sector | |
| 1014 numbers of the directory and its parent directory, respectively (see 3.7.3). | |
| 1015 </para> | |
| 1016 <para> | |
| 1017 Directories cannot be copied or listed - the "dir" command is | |
| 1018 used instead. Directories also cannot be deleted directly (see 3.5). | |
| 1019 </para> | |
| 1020 </section> | |
| 1021 | |
| 1022 <section> | |
| 1023 <title>Miscellaneous File Usage</title> | |
| 1024 <para> | |
| 1025 OS-9's basic file functions are so versatile it is possible to | |
| 1026 devise an almost unlimited number of special-purpose file formats | |
| 1027 for particular applications, which do not fit into any of the three | |
| 1028 previously discussed categories. | |
| 1029 </para> | |
| 1030 <para> | |
| 1031 Examples of this category are COBOL Indexed Sequential (ISAM) | |
| 1032 files and some special word processor file formats which allow | |
| 1033 random access of text lines (See 3.9.2). As discussed in Sec. | |
| 1034 3.9.1, most OS-9 utility commands work with any file format including | |
| 1035 these special types. In general, the "dump" command is the preferred | |
| 1036 method for examining the contents of unusually formatted files. | |
| 1037 </para> | |
| 1038 </section> | |
| 1039 </section> | |
| 1040 | |
| 1041 <section> | |
| 1042 <title>Physical File Organization</title> | |
| 1043 <para> | |
| 1044 OS-9's file system implements a universal logical organization | |
| 1045 for all I/O devices that effectively eliminates most hardware-related | |
| 1046 considerations for most applications. This section gives | |
| 1047 basic information about the physical file structure used by OS-9. | |
| 1048 For more information, see the OS-9 System Programmer's Manual. | |
| 1049 </para> | |
| 1050 <para> | |
| 1051 Each OS-9 file is comprised of one or more sectors which are | |
| 1052 the physical storage units of the disk systems. Each sector holds | |
| 1053 exactly 256 data bytes, and disk is numbered sequentially starting | |
| 1054 with sector zero, track zero. This number is called a "logical | |
| 1055 sector number", or <emphasis>LSN</emphasis>. | |
| 1056 The mapping of logical sector numbers to | |
| 1057 physical track/sector numbers is done by the disk driver module. | |
| 1058 </para> | |
| 1059 <para> | |
| 1060 Sectors are the smallest allocatable physical unit on a disk | |
| 1061 system, however, to increase efficiency on some larger-capacity disk. | |
| 1062 systems, OS-9 uses uniform-sized groups of sectors, called | |
| 1063 <emphasis>clusters</emphasis>, | |
| 1064 as the smallest allocatable unit. Cluster sizes are always an | |
| 1065 integral power of two (2, 4, 8, etc.). One sector of each disk is | |
| 1066 used as a <emphasis>bitmap</emphasis> (usually LSN 1), | |
| 1067 in which each data bit corresponds | |
| 1068 to one cluster on the disk. The bits are set and cleared to | |
| 1069 indicate which clusters are in use (or defective), and which are | |
| 1070 free for allocation to files. | |
| 1071 </para> | |
| 1072 <para> | |
|
149
bb3e4d64103a
Made the word "Dragon" an entity, thereby making it replacable with "Color"
roug
parents:
144
diff
changeset
|
1073 The &make; Computer disk system uses the following format: |
| 144 | 1074 </para> |
| 1075 <itemizedlist mark="square"> | |
| 1076 <listitem><para> | |
| 1077 double density recording on one side | |
| 1078 </para></listitem> | |
| 1079 <listitem><para> | |
| 1080 40 tracks per disk | |
| 1081 </para></listitem> | |
| 1082 <listitem><para> | |
| 1083 18 sectors per track | |
| 1084 </para></listitem> | |
| 1085 <listitem><para> | |
| 1086 one sector per cluster | |
| 1087 </para></listitem> | |
| 1088 </itemizedlist> | |
| 1089 <para> | |
| 1090 Each file has a directory entry (see 3.9.5) which includes the | |
| 1091 file name and the logical sector number of the file's "file descriptor | |
| 1092 sector", which contains a complete description of the file | |
| 1093 including: | |
| 1094 </para> | |
| 1095 <itemizedlist mark="square"> | |
| 1096 <listitem><para> | |
| 1097 attributes | |
| 1098 </para></listitem> | |
| 1099 <listitem><para> | |
| 1100 owner | |
| 1101 </para></listitem> | |
| 1102 <listitem><para> | |
| 1103 date and time created | |
| 1104 </para></listitem> | |
| 1105 <listitem><para> | |
| 1106 size | |
| 1107 </para></listitem> | |
| 1108 <listitem><para> | |
| 1109 segment list (description of data sector blocks) | |
| 1110 </para></listitem> | |
| 1111 </itemizedlist> | |
| 1112 <para> | |
| 1113 Unless the file size is zero, the file will have one or more | |
| 1114 sectors/clusters used to store data. The data sectors are grouped | |
| 1115 into one or more contiguous blocks called "segments". | |
| 1116 </para> | |
| 1117 </section> | |
| 1118 </chapter> |