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