Consolidate license copies
[its.git] / sysdoc / ufd.100
1 Copyright (c) 1999 Massachusetts Institute of Technology
2
3 This program is free software; you can redistribute it and/or modify
4 it under the terms of the GNU General Public License as published by
5 the Free Software Foundation; either version 3 of the License, or (at
6 your option) any later version.
7
8 This program is distributed in the hope that it will be useful, but
9 WITHOUT ANY WARRANTY; without even the implied warranty of
10 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
11 General Public License for more details.
12
13 You should have received a copy of the GNU General Public License
14 along with this program; if not, write to the Free Software
15 Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
16 ------------------------------
17
18 Disk file directories are each one disk block
19 of data (2000 words).  The file directory contains
20 all the data necessary to maintain the actual files on the disk.
21 The directory is arranged in two main portions.  The name area
22 contains identification data for every file said
23 to be "in that directory", including the file's names, time of
24 creation, and a pointer to the descriptor area.  The descriptor
25 area portion of a file directory describes exactly where on the disk
26 the files are.
27
28 The file SYSTEM; FSDEFS > contains a page beginning
29 ";UFD INFO", UFD meaning "user file directory".
30 This page contains the assignment of most of the important
31 symbols which define the directory format parameters.  The following
32 description assumes the values of the parameters when this
33 document was written, and although most of the parameters are not
34 apt to change, there is this possibility.
35
36 The first word of the file directory contains a pointer to the beginning
37 of the descriptor area, and the second word points to the beginning
38 of the name area.  The third word of the directory contains the sixbit
39 user name of the directory.
40
41 The name area of the directory contains 5 words
42 of information for every file.
43
44 1 - FN1 (SIXBIT)
45 2 - FN2 (SIXBIT)
46 3 - STATUS BITS & RANDOM INFO
47 4 - CREATION DATE
48 5 - DATE LAST REFERENCED
49
50 The fourth word contains the compacted date and time of
51 creation for the file.  The right half of this word is the
52 time of day since midnight in half-seconds.  Bits 3.1-3.5
53 are the day, bits 3.6-3.9 are the month, and bits 4.1-4.7
54 are the year.  The fifth word's left half holds the date the
55 file was last referenced.  This is in the same format as the
56 creation date.
57
58         4.9-4.8 - UNUSED
59         4.7-4.1 - YEAR (RELATIVE TO 1900)
60         3.9-3.6 - MONTH (1=JAN)
61         3.5-3.1 - DAY (1-31)
62         2.9-1.1 - (RH) # HALF-SECS SINCE LAST MIDNIGHT (4th wd only)
63
64 The third word in the name area for every file contains all
65 the information about the file's status, with bits
66 indicating things such as whether the file has been deleted,
67 whether it is open for writing, etc.
68
69         4.9  -  FILE DUMPED TO TAPE
70         4.8  -  UNUSED
71         4.7-3.7 - # WORDS IN LAST BLOCK OF FILE
72         3.6  -  FILE DELETED FROM UNMOUNTED PACK
73         3.5  -  FILE WILL DISAPPEAR WHEN CLOSED BY ALL WHO HAVE IT OPEN
74         3.4  -  UNUSED
75         3.3  -  OPEN FOR WRITING
76         3.2  -  UNUSED
77         3.1  -  THIS FILE IS LINK
78         2.9-2.5 - PACK # FILE STORED ON
79         2.4-1.1 - BYTE ADDR PTR TO START OF FILE'S DESCRIPTOR BYTES
80
81 2.4-1.1 is actually a byte address relative to a point 11.
82 words from the beginning of the directory.  The byte size is
83 6 characters, so the word address is the pointer divided by
84 6, and the byte within that word can easily be determined by
85 the remainder of the division.  Once the correct byte
86 pointer is determined, successive ILDBs will get the
87 descriptor bytes of the file.  Assuming the contents of A
88 points to the third word of the name block for a file, here
89 is a piece of code which will generate the correct byte
90 pointer in N, all set for ILDBing, with N indexing B, which
91 holds the correct word address:
92 ;B=2
93 ;C=3
94 ;UFDBYT==6              ;SIZE OF BYTES
95 ;UFDBPW==36./UFDBYT     ;NUMBER OF BYTES PER WORD
96 ;FDIRBF IS FIRST LOCATION IN DIRECTORY, UDDESC IS 11..
97
98         LDB B,[1500,,A]         ;GET BYTE ADDRESS
99         IDIVI B,UFDBPW          ;CHANGE TO WORD ADDRESS
100         ADDI B,FDIRBF+UDDESC
101         MOVNI N,-UFDBPW(C)
102         IMULI N,UFDBYT          ;Only works because UFDBYT divides 36.
103         HRLI N,060200           ;ASSUMING B=2 !!!!
104         ROT N,30.
105 ;END OF ROUTINE
106
107 If the file is a link, the descriptor bytes themselves specify
108 what directory and file names this file is linked to.  These
109 three args are the only pieces of information in the descriptor
110 area for links.  Each name is terminated by a semicolon unless
111 it is a full six characters long.  Colon quotes the character
112 that follows it.
113
114 For normal disk files, every descriptor byte tells where the
115 next block, or group of blocks, of the file resides on the
116 disk.  A byte with a value of 0 ends the description.  A byte
117 with the value 31. (UDWPH) is an ignored place-holder.  If
118 the byte is from 1 through 12. (UDTKMX), that many blocks
119 of the file reside contiguously.  If the byte is from 13.
120 through 30., skip that many blocks minus 12., and the next
121 block, after the ones skipped, is in the file.  If the 40
122 bit of the byte is set, the low 4 bits of that byte together
123 with the next 2 bytes tell where the next block of the file
124 is to be found.  When the 40 bit is set, the 20 bit is a
125 flag which, if on, says that blocks that follow each contain
126 a word count in their last word.
127
128 Occasionally when a program tries to open a file for
129 writing, there is no more room in the file directory for the
130 file's specifications, not because there is really no room,
131 but because non-existant (deleted) files still have
132 descriptors etc. taking up unnecessary room.  When this
133 happens, the system rearranges the directory, a
134 "housekeeping" chore known as garbage collecting.  Garbage
135 collecting a file directory takes about 1-2 minutes of
136 realtime waiting, usually.  If the system is provoked to
137 garbage collect FOO's file directory, it announces the
138 occasion on the system job console with the message "GC OF
139 USER DIR FOO".  During the ordeal, the job provoking the
140 collection may not be control-Zed amongst other things.  If
141 you try to control-Z it, however, the only noticeable
142 difference to you will be a long wait before DDT knows to
143 recognize your request for interruption.  If ^Z seems not to
144 be "doing much", try checking the system job console to see
145 if you are being garbage collected.
146
147 File directories are read by timesharing programs the way
148 any disk files are read.  Merely use the file name .FILE.
149 (DIR) for the .OPEN, and the system will supply you with the
150 directory instead of a file.  If the mode is ASCII, the data
151 you receive after .OPENing .FILE.  (DIR) is the ASCII string
152 you normally see, upon doing :LISTF DSK: or DSK\ 6 in DDT or
153 EYDSK:\e\e in TECO.  If the mode for the .OPEN is image, the
154 data you receive is the actual file directory as advertised,
155 and as stored on the disk.  As already mentioned, it is
156 exactly 2000 octal words long, and is organized exactly as
157 described above.  Any program opening disk file directories
158 for the purpose of seeing what files are on the directory
159 will be far more efficient opening the directory in image as
160 opposed to ASCII mode.  Such programs, when written in MIDAS
161 assembly language, should .INSRT SYSTEM; FSDEFS > and use
162 the symbolic definitions therein, for greater clarity and
163 immunity to system changes.
164
165 \f