Method and system for traversing linked list record based upon write-once predetermined bit value of secondary pointers5247658Abstract A method and apparatus for storing files on a computer file storage device. The files are organized into an hierarchical directory structure. The directory structure comprises directory entries and file entries. The file entries and directory each contain a primary and a secondary pointer. The secondary pointer is initially set to a predefined value. When an entry is to be updated, the secondary pointer is overridden with a value that points to the superseding entry. This directory structure is especially suitable to be used in a write-once computer memory. Claims We claim: Description DESCRIPTION
TABLE 1
______________________________________
typedef boot.sub.-- record {
word standard.sub.-- identifier;
dword unique.sub.-- identifier;
word FS.sub.-- version.sub.-- write;
word min.sub.-- FS.sub.-- version.sub.-- to.sub.-- read;
byte pointer.sub.-- size;
FEptr root.sub.-- directory;
char vol.sub.-- label[11]
char boot.sub.-- info[..];}
standard.sub.-- identifier
a value which indicates that the
media supports this file system
unique.sub.-- identifier
combined with vol.sub.-- label is a
unique identifier for the
particular FEProm
FS.sub.-- version.sub.-- write
version number in high byte and
revision number in low byte of
file system that is required to
write to this volume
min.sub.-- FS.sub.-- version.sub.-- to.sub.-- read
version number in high byte and
revision number in low byte of
the earliest version of file
system that directory structure
is compatible with
pointer.sub.-- size
number of bits used in pointers
root.sub.-- directory
pointer to root directory
vol.sub.-- label
eleven character label
boot.sub.-- info
data relating to booting the
operating system
typedef status.sub.-- type {
unsigned bit.sub.-- 0:1;
unsigned bit.sub.-- 1:1;
unsigned bit.sub.-- 2:1;
unsigned bit.sub.-- 3:1;
unsigned bit.sub.-- 4:1;
unsigned bit.sub.-- 5:1;
unsigned bit.sub.-- 6.sub.-- 7:2;}
typedef FEDirEntry {
FEPtr sibling;
char name[8];
char ext[3];
status.sub.-- type
status;
FEPtr primary.sub.-- ptr;
FEPtr secondary.sub.-- ptr;
byte attributes;
short time;
short date;};
typedef FEFileEntry {
FEPtr sibling;
char name[8];
char ext[3];
status.sub.-- type
status;
FEPtr primary.sub.-- ptr;
FEPtr secondary.sub.-- ptr;
byte attributes;
short time;
short date;
FEPtr extent.sub.-- location;
short extent.sub.-- length;}
typedef FEFileInfo {
byte status;
FEPtr primary.sub.-- ptr;
FEPtr secondary.sub.-- ptr;
FEPtr extent.sub.-- location;
short extent.sub.-- length;
byte attributes;
short time;
short date;
sibling pointer to next directory entry in
sibling chain
name directory/file name
ext file extension
status
bit # meaning
0 1:record exists in the directory
structure
0:record has been deleted from the
directory structure
1 1:record contains current attributes,
date, and time data
0:record contains data that has been
superseded or no data
2 1:FEFileEntry
0:FEDirEntry
3 1:sibling is FNULL
0:sibling is not FNULL
4 1:primary.sub.-- ptr is FNULL
0:primary.sub.-- ptr is not FNULL
5 1:secondary.sub.-- ptr is FNULL
0:secondary.sub.-- ptr is not FNULL
6-7 reserved
primary.sub.-- ptr
FEDirEntry: points to the first
FEDirEntry or FEFileEntry on the
next lower level in the directory
hierarchy; only valid if
secondary.sub.-- ptr equals FNULL
FEFileEntry: points to the linked
list of FEFileInfo entries associated
with the file; only valid if
secondary.sub.-- ptr equals FNULL
FEFileInfo: points to the next
FEFileInfo entry for the file; only
valid if secondary.sub.-- ptr equals
FNULL
secondary.sub.-- ptr
FEDirEntry: points to the next
FEDirEntry entry for the directory;
the last entry in the linked list
contains the current information for
the directory; only valid if not
FNULL
FEFileEntry: points to the next
FEFileEntry entry for the file; the
last entry in the linked list contains
the current information for the file;
only valid if not FNULL
FEFileInfo: points to the next
FEFileInfo entry for the file; only
valid if not FNULL
attributes file attributes such as read-only,
read/write, etc.
time time of creation or modification
date date of creation or modification
extent.sub.-- location
points to start of extent
extent.sub.-- length
length of extent in bytes
______________________________________
The present invention provides a directory-based hierarchical file system for a FEProm device. A hierarchical file system provides a way to store files in logical groupings. A preferred embodiment uses a linked-list data structure to implement both the directory hierarchy and the internal file storage. FIG. 1A shows a typical hierarchical directory structure. The MS-DOS operating system, which is available from Microsoft Corporation of Redmond, Wash., implements a file system with a hierarchical directory structure. As shown in FIG. 1A, the ROOT directory contains two subdirectories (DOS and WORD) and two files (AUTOEXEC.BAT and COMMAND.COM) at the next lower level. The directory DOS contains one file (FORMAT.EXE). The directory WORD contains two subdirectories (DAVID and MARY) at the next lower level. The directory DAVID contains one file LETTER1.DOC. The directory MARY contains three files LETTER1.DOC, LETTER2.DOC, and LETTER3.DOC. FIG. 1B shows a possible linked list that in a preferred embodiment implements the directory structure of FIG. 1A. The ROOT directory record (the terms record and entry are used interchangeably in this specification) has a pointer which points to a linked list of subdirectory records and file records at the next lower level. The subdirectory record DOS has a pointer to the file record at the next lower level, and the subdirectory record WORD has a pointer to a linked list of subdirectory records at the next lower level. The subdirectory record DAVID has a pointer to the file at the next lower level, and the subdirectory record MARY has a pointer to a linked list of file records at the next lower level. The template 10 shows the record layout used throughout the drawings. FIG. 1B represents just one possible linked list arrangement that represents FIG. 1A. The arrangement would be different if files had been added but then deleted or if the name of a directory was changed. FIG. 1C shows another possible arrangement. FIG. 1C represents the same directory hierarchy as FIG. 1A, but the directory BILL existed at one time but has been deleted. Because a FEProm device can be written only once, in a preferred embodiment of the present invention, directory record BILL, as shown in FIG. 1C, is not physically removed from the linked list. A directory or file record is deleted from the linked list by logically clearing the exist/delete bit of the status byte of the directory or file entry. If the directory or file was stored on a computer disk, then directory record BILL could be physically removed by rewriting the pointer in directory record DAVID to point to directory record MARY. A preferred embodiment also uses a linked-list data structure to link the extents that compose a file. Each file has a file record associated with it that contains, among other data, the name of the file and that is linked into the directory hierarchy as described above. An extent is a contiguous area of memory that contains data for the file. Each file comprises one or more extents which contain the file data. Each extent has an extent record associated with it. The extent record contains, among other data, the start address of the extent and the length of the extent. FIG. 2A shows the extents of the file " A D.DAT". The file record (R0) also serves as the extent for the first extent in a file and contains a pointer to the first extent (E0). The extent records (R1, R2, and R3) are linked and contain a pointer to the corresponding extents (E1, E2, and E3). The file is the logical concatenation of extents E0, E1, E2, and E3. FIG. 2A represents just one possible linked list arrangement for file " A D.DAT". FIG. 2B shows another arrangement that represents the same file. The extent E4 was added to the file but then deleted. In a preferred embodiment, the file record R4 is not physically removed from the linked list of extents that compose the file. Rather, the record R4 is logically removed by setting the exist/delete bit of the status byte to indicate the record is deleted. In a preferred embodiment of the present invention, the file system adds directory records, file records, extent records, and extents by allocating space starting from address zero in the FEProm. The file system treats the FEProm as a stack-like device. Data is pushed onto the stack to effect allocation, but data is never popped from the stack. FIG. 3 shows the allocated and unallocated portion of a FEProm. The variable first.sub.-- unallocated points to the lowest address in the unallocated portion. Each byte of the unallocated portion contains FNULLs, since it has not yet been written to by the file system. An FNULL is a byte that contains all 1s. When a FEProm is erased each byte contains an FNULL. In a preferred embodiment, the first.sub.-- unallocated pointer is not stored on the FEProm. When a FEProm is first connected to the computer (i.e., put on-line), the file system searches the FEProm from the highest address location to the lowest address for the first occurrence of a non-FNULL byte. The next higher address is the start of the unallocated area (first.sub.-- unallocated). The file system should ensure that the data stored at the end of the allocated portion does not contain a FNULL. This can be accomplished by adding a non-FNULL byte to the end of any record or extent that ends in an FNULL. Table 1 contains several data structures used in a preferred embodiment of the present invention. The structures are shown in C programming language format along with a description of the structure variables. The first data structure stored on the FEProm is the boot.sub.-- record. The boot.sub.-- record contains some general information relating to the identification of the FEProm, the version number of file system that can access the FEProm, the pointer.sub.-- size variable, and the root directory variable. The pointer.sub.-- size indicates the byte-size of the pointers stored in the FEProm. For example, a pointer size with value of 3 indicates that each pointer is three bytes. The root.sub.-- directory is a pointer to the root directory stored on the FEProm. The second and third structures are the FEDirEntry and FEFileEntry structures. One of these structures is allocated for each directory and file. The structures are identical except that the FEFileEntry has extent location and extent length variables. The variable sibling points to the next sibling in the linked list of FEDirEntry and FEFileEntry structures at the same level in the directory hierarchy. The variables primary.sub.-- ptr and secondary.sub.-- ptr are fully described below. Described below is a preferred method of a file system for a FEProm. The file system allows for directories to be added and deleted, and files to be created, extended, and modified. FIG. 4 shows a flow diagram for the routine that adds a directory to a storage device. The input parameters to this routine are the complete pathname of the new directory and attribute data for the new directory. The term attribute data as used below refers to the attribute, date, and time values. This routine will set the variable P to point to the parent directory and the variable C to point to the child directory. For example, the path name " P C" means that a directory "C" is to be created that is a subdirectory of "P," which is a subdirectory of the root directory. FIG. 5 shows when "C" would be the first subdirectory of "P," and FIG. 6 shows when "C" would not be the first subdirectory of "P". Referring to FIGS. 5 and 6, the solid lines show the directory structure before "C" is added and the broken lines show the directory structure after "C" is added. In block 401 of FIG. 4, the system locates directory "P" by following the path from the root directory and setting variable P to the address of "P" directory. In block 402, the system allocates a new directory entry of the record type FEDirEntry for directory "C." The system sets the variable C to the variable first.sub.-- unallocated and allocates the space by incrementing the variable first.sub.-- unallocated by the size of an FEDirEntry record. FIGS. 7A and 7B show the address space before allocation and after allocation of the FEDirEntry record, respectively. In block 403, the system sets the variables name, time, date, and attribute in the newly allocated record. In block 404, the system sets the status bit to indicate that the newly allocated entry is a directory entry, rather than a file entry. In blocks 405 through 410, the system links the new directory entry into the old directory structure. In blocks 406 through 409, the system handles the situation where the new directory is not the first subdirectory of "P." In block 410, the system handles the situation where the new directory is the first subdirectory of "P." In block 405, if P-->primary.sub.-- ptr equals FNULL, then the "P" directory has no subdirectory and the system continues at block 410, else the "P" directory has or has had a subdirectory (discussed below), and the system continues at block 406. In block 410, the system sets P-->primary.sub.-- ptr equal to the variable C, the address of the newly allocated directory entry to effect the linking to the new directory and then the routine is done. In block 406, the system sets the variable next.sub.-- ptr equal to P-->primary.sub.-- ptr. The variable next.sub.-- ptr contains the next directory in the chain of sibling subdirectories. In block 407, if next.sub.-- ptr-->sibling equals FNULL, then the end of the chain of siblings has been reached and the system continues at block 409, else the system continues at block 408. In block 408, the system sets next.sub.-- ptr equal to next.sub.-- ptr-->sibling, which advances next.sub.-- ptr to point to the next directory in the chain, and continues at block 407 to determine if the end of the chain has been reached. In block 409, the system sets next.sub.-- ptr>sibling equal to C, the address of the newly allocated directory record and then the routine is done. FIG. 8 shows a flow diagram of the routine that adds a record into the file system for a new file. Since FEFileEntry records are simply leaf nodes of the hierarchical tree-structured file system, the routine that adds the FEFileEntry records is very similar to the routine for FEDirEntry records, which is Add Directory, shown in FIG. 4. The significant difference is that the status bit that indicates the record is a directory is not cleared as in block 404 of FIG. 4. Thus, the status bit indicates the record is a file record. FIG. 9 shows a flow diagram of the routine that adds data to a newly created file. The routine is passed the complete pathname, the data to write, and the number of bytes to write. The routine allocates space in the FEProm, writes the data, and then updates the FEFileEntry record for the file. In block 901 and 902, the system allocates the space in the FEProm for the extent. In block 901, the system sets the pointer extent.sub.-- start equal to first.sub.-- unallocated. In block 902, the system increments first.sub.-- unallocated by the number of bytes to write. In block 903, the system writes the data to the FEProm at the location pointed to by extent.sub.-- start. In block 904, the system locates the FEFileEntry record for the file by tracing down the pathname and sets F to point to that record. In block 905, the system sets F-->extent.sub.-- location equal to extent.sub.-- start. In block 906, the system sets F-->extent.sub.-- length equal to the number of bytes to write and then the routine is done. FIGS. 10A and 10B show a flow diagram of the routine to add data onto the end of a file. This routine is passed the complete pathname, the data to write, and the number of bytes to write. FIG. 11 shows a sample layout of the directory structure that contains the file " L.dat" that is to be extended. The solid lines show the structure before the file is extended and the broken lines show the structure after the file is extended. Initially, the file "L.DAT" has a FEFileEntry record and a FEFileInfo record associated with it. Each of these records has a data extent, D1 or D2. The broken lines represent a FEFileInfo record with the data to be added to the file in extent D3. Referring to FIGS. 10A and 10B in block 1001, the system allocates a new FEFileInfo record in the FEProm and sets the pointer FI to contain the address of that record. In block 1002, the system sets FI-->date, FI-->time, and FI-->attribute. In blocks 1003 and 1004, the system allocates space in the FEProm for the data that is to extend the file. In block 1003, the system sets the variable extent.sub.-- start equal to first.sub.-- unallocated. In block 1004, the system increments first.sub.-- unallocated by the number of bytes to write. In block 1005, the system writes the data to the FEProm starting at the location pointed to by extent.sub.-- start. In block 1006, the system locates the FEFileEntry record for the file to be extended and sets FE to point to that record. In a preferred embodiment, the system would locate the FEFileEntry record before allocating the new extent and FEFileInfo record to ensure that the file exists before any allocation is done. In blocks 1007 through 1012, the system locates the last FEFileInfo record for the file to be extended. The system follows the primary.sub.-- ptr or the secondary.sub.-- ptr of the FEFileEntry record and the FEFileInfo records. A non-FNULL value in the secondary.sub.-- ptr field indicates that the record pointed to by the primary.sub.-- ptr has been superseded by the data in the record pointed to by the secondary.sub.-- ptr. In block 1007, the system sets pointer next.sub.-- ptr equal to FE, which is the address of the FEFileEntry record. In block 1008A, the system sets the pointer prev.sub.-- ptr equal to next.sub.-- ptr. When the last FEFileInfo record in the file is located, the pointer prev.sub.-- ptr will contain the address of that record. In block 1008B, the system sets the next.sub.-- to>indicate that the attributes, date, and time are superseded. This will ensure that the newly allocated FEFileInfo record will be the only record for the file with current attribute, date, and time data. In block 1009, if next-->secondary.sub.-- ptr equals FNULL, then the data in the record pointed to by the primary.sub.-- ptr has not been superseded and the system continues at block 1010, else the system continues at block 1011. In block 1010, the system sets next.sub.-- ptr equal to next.sub.-- ptr-->primary.sub.-- ptr to get the address of the next record in the linked list and continues at block 1012. In block 1011, the system sets next equal to next.sub.-- ptr-->secondary.sub.-- ptr to get the address of the next record in the linked list and continues at block 1012. In block 1012, if next.sub.-- ptr equals FNULL, then the end of the list has been reached and the system continues at block 1013, else the system continues at 1008A to process the next record in the list. In block 1013, the system sets prev.sub.-- ptr-->primary.sub.-- ptr equal to FI to effect the extending of the file and the routine is done. FIG. 12 shows a flow diagram for the routine that updates the data in a file. The parameters for this routine are R, the address of the FEFileEntry or FEFileInfo block that is to have its associated extent modified; extent.sub.-- offset, the offset into the extent for the new data; new.sub.-- data, the new data; data.sub.-- length, the length of the new data. Since the FEProm is effectively a write once device, at least until everything is erased, an area where data is stored cannot be rewritten when an update to a file occurs. In a preferred embodiment, the updated data is written to a different area of the FEProm, as described below. FIG. 13 shows a typical portion of the linked list of the FEFileInfo records for a file. The Update.sub.-- File routine will replace the data represented by the shaded area. FIG. 14 shows the structure of the linked list after the modified data has been written to the FEProm. Three FEFileInfo records, R1, R2, and R3, have been inserted into the linked list. The entire extent is not rewritten, rather only the portion that actually changed is rewritten. The routine divides the extent into three sections, D1, D2, and D3. Sections D1 and D3 contain data that is not changed by the update, and section D2 contains the data that will change. Each section will have a corresponding FEFileInfo record. The FEFileInfo records R1, R2, and R3 are linked through their primary.sub.-- ptr. Also, the extent.sub.-- location field in R1 and R3 point to their corresponding extent sections and the extent length fields are set. However, a new extent has been allocated for the changed data corresponding to the new D2 section, which is pointed to by record R2. The secondary.sub.-- ptr of record R points to FEFileInfo R1 to indicate that the primary.sub.-- ptr of R is suspended. The primary.sub.-- of FEfileInfo record R3 is set to the value contained in the primary.sub.-- ptr of FEFileInfo record R to complete the link. In block 1201, the system allocates three FEFileInfo records and sets the pointers R1, R2, and R3 to contain the addresses. R1 is allocated with and R2 and R3 are allocated without the attribute data. In block 1202, the system sets R1-->time, R1-->date, and R1-->attributes and R2-->status and R3-->status to superseded. In block 1203 and 1204, the system allocates a record of data.sub.-- length for the new data. In block 1203, the system sets the variable extent.sub.-- start equal to first.sub.-- unallocated. In block 1204, the system increments first.sub.-- unallocated by data.sub.-- length. In block 1205, the system writes new.sub.-- data to the FEProm starting at the address extent.sub.-- start. In blocks 1206 through 1208, the system sets the data in FEFileInfo record R2. In block 1206, the system sets R2-->extent.sub.-- location equal to extent.sub.-- start. In block 1207, the system sets R2-->extent.sub.-- length equal to data.sub.-- length. In block 1208, the system sets R2-->primary.sub.-- ptr to R3. In blocks 1209 through 1211, the system sets the data in FEFileInfo record R3. In block 1209, the system sets R3-->extent.sub.-- location equal to R-->extent.sub.-- location plus extent.sub.-- offset plus data.sub.-- length, which is the start address of section D3. In block 1210, the system sets R3-->extent.sub.-- length equal to R-->extent.sub.-- length minus R3-->extent.sub.-- location. In block 1211, the system sets R3-->primary.sub.-- pointer equal to R-->primary.sub.-- ptr. In blocks 1212 through 1214, the system sets the data in FEFileInfo record R1. In block 1212, the system sets R1-->extent.sub.-- location equal to R-->extent.sub.-- location. In block 1213, the system sets R-->extent.sub.-- length equal to extent.sub.-- offset. In block 1214, the system sets (R1-->primary.sub.-- otr to R2. In block 1215, the system sets R-->secondary.sub.-- ptr equal to R1, which indicates that the primary.sub.-- ptr is superseded, and then the routine is done. FIGS. 15 and 16 show the FEFileInfo list for a couple special cases of file updates. The routine for processing for these special cases is a subset of the routine needed for processing the general case, Update.sub.-- File, shown in FIG. 12. In FIG. 15, data starting at the beginning of an extent is updated. Section D1 contains the data at the beginning of the extent to be updated and section D2 contains the data at the end of the extent that is not updated. Only two new FEFileInfo records are needed. The first FEFileInfo record R1 points to the new data and the second FEFileInfo record R2 points to the old data. A similar situation occurs when data that ends on an extent boundary is updated as shown in FIG. 16. FIG. 17 shows a linked list for FEFileInfo records when the updated data spans extent boundaries. FIG. 18 shows a flow diagram of a routine that deletes a directory or file from the FEProm. This routine clears the exist/delete bit in the FEDirEntry. In block 1801, the system locates the directory or file to be deleted and sets the pointer D to contain the address of the directory or file. In block 1802, the system sets D-->status to indicate that the directory or file is deleted and the routine completes. The name of a directory or file is changed by allocating a new FEDirEntry or FEFileEntry, respectively, and then setting the secondary.sub.-- ptr of the old entry to point the new entry. FIG. 20 shows the file entry for "D.DAT" in solid lines and the changes in broken lines when the name is changed to "B.DAT." The new entry points to the linked list of FEFileInfo entries, the directory structure, and the extent associated with the old entry. FIG. 19 is a flow diagram of a preferred subroutine that implements the changing of a file name. (The subroutine for changing a directory is similar, except that there are no associated extents.) The input parameters to this routine are the pathname of the file and the new file name. In block 1901, the system searches through the directory structure and locates the file whose name is to be changed and sets the variable P to point to the FEFileEntry. In block 1902 and 1903, the system searches for the last FEFileEntry in the linked list of entries for the file. A file will have an entry for each name change In block 1902, if P-->secondary.sub.-- ptr equals FNULL, then P points to the end of the linked list and the system continues at block 1904, else P does not point to the end of the linked list and the system continues at block 1903. In block 1903, the system sets P equal to P-->secondary.sub.-- otr to walk through the linked list. In block 1904, the system allocates a new FEFileEntry and sets the variable C to point to the entry. In block 1905, the system set C-->name equal to the new file name. In block 1906, the system sets C-->sibling equal to P-->sibling to link the entry into the directory hierarchy. In blocks 1907 and 1908, the system sets C-->extent.sub.-- location and C-->extent.sub.-- length equal to P-->extent.sub.-- location and P-->extent.sub.-- length, respectively, to link the new entry to the extent. In block 1909, the system sets C-->primary.sub.-- ptr equal to P-->primary.sub.-- ptr to link the new entry to the list of extents. In block 1910, the system sets P-->secondary.sub.-- ptr equal to C to complete the replacement of the old entry and the routine completes. The attribute data associated with a file are changed by adding a new FEFileInfo entry onto the linked list of FEFileInfo entries. All FEFileInfo entries except the last are set to indicate that the attribute data have been superseded. FIG. 22 shows the linked list arrangement before the attribute data change in solid lines and after the attribute data the change in broken lines. No extent is associated with the FEFileInfo entry that is added as a result of an attribute data change. FIGS. 21A and 21B show a flow diagram of a routine that changes the attribute data of a file. The input parameters are the pathname and the attribute data. In block 2101, the system searches through the directory structure to locate the file and sets the variable P to point to the FEFileEntry. In block 2102 and 2103, the system searches for the last FEFileEntry in the linked list of entries for the file. A file will have an entry for each name change. In block 2102, if P-->secondary.sub.-- ptr equals FNULL, then P points to the end of the linked list and the system continues at block 2104, else P does not point to the end of the linked list and the system continues at block 2103. In block 2103, the system sets P equal to P-->secondary.sub.-- ptr to walk through the linked list. In block 2104, the system sets the variable C equal to P-->primary.sub.-- ptr, which points to the linked list of FEFileInfo entries for the file. In blocks 2105 through 2110, the system searches through the FEFileInfo entries for the last entry. If a secondary.sub.-- ptr is set, the system follows that path, otherwise it follows the primary.sub.-- ptr. If both primary.sub.-- ptr and secondary.sub.-- ptr are equal to FNULL, then the system has located the end of the linked list. In block 2105, if C-->secondary.sub.-- ptr equals FNULL, then the system continues at block 2108, else the system continues at block 2106. In block 2106, the system sets C-->status to indicate that the attribute data are superseded. The new FEFileInfo entry will contain the new attribute data. In block 2107, the system sets C equal C-->secondary.sub.-- ptr to traverse the linked list and the system loops to 2105. In block 2108, if C-->primary.sub.-- ptr equals FNULL, then C points to the last FEFileInfo record in the list and the system continues at block 2111, else the system continues at block 2109. In block 2109, the system sets C-->status to indicate that the attribute data are superseded. The new FEFileInfo entry will contain the new attribute data. In block 2110, the system sets C equal C-->primary.sub.-- ptr to traverse the linked list and the system loops to 2105. In block 2111, the system allocates a new FEFileEntry and sets the variable R to point to the entry. In block 2112, the systems sets the attribute data for the new file entry. In block 2113, the system sets C-->primary.sub.-- ptr equals R to link the new entry with the other FEFileInfo entries and the routine completes. In an alternate preferred embodiment, the FEFileEntry records and the FEFileInfo records are allocated after the space for extent is allocated. Storing in this manner has two advantages. First, it ensures that the allocated space will never end in an FNULL. Second, several writes can be combined into one large extent. The combining of the writes can occur up to the point at which FEDirEntry, FEFileEntry, or a FEFileInfo (for a different file) are to be added to the FEProm. At that point, the combined FEFileInfo record could be written out. Although the present invention has been described in terms of preferred embodiment, it is not intended that the invention be limited to this embodiment. Modifications within the spirit of the invention will be apparent to those skilled in the art. The scope of the present invention is defined by the claims that follow.
|
Same subclass Same class Consider this |
||||||||||