JPH05342075A - File managing system - Google Patents

Abstract

PURPOSE:To enable link processing between directory files and to easily grasp entire file structure by storing the retrieval information of the dummy directory file in the real directory file. CONSTITUTION:When preparing the dummy directory file (ID) of [/usr1/sum] with [/usr3/jun] as the real directory file (RD,) and (i) node having the same substance information as the RD of a link source is applied to the ID of a link destination. Further, the (i) node number and file name of the ID are added to the master directory file [usr1] of the ID of the link destination. Thus, link processing is enabled between the directory files. On the other hand, the (i) node number of the ID at the link destination and the (i) node number of the master directory file are added to an ID list. Therefore, the existence of the ID can be recognized from the file or directory file managed by the RD.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a file management system, and more particularly to a link process between directory files.

[0002]

2. Description of the Related Art Generally, in a file management system such as UNIX, a plurality of files are managed in a hierarchical structure. FIG. 6 shows a file management system of UNIX (trademark) (4.3 BSD version). The physical disk 51 is divided into a plurality of logical partitions called partitions. In this example, it is divided into partitions 51a, 51b, 51c, 51d. It should be noted that one partition constitutes one file system.

Each partition is divided into a plurality of cylinder groups, and one of the cylinder groups 55 is composed of a super block 57, a cylinder group block 59, an inode list 61 and a data block 63. The same applies to other cylinder groups.

The super block 57 stores information necessary for managing the file system, such as the size of the file system. One super block may be provided for each file system, but the same information is stored in each cylinder group block in order to improve reliability. The cylinder group block 59 stores bitmap information and statistical information of valid blocks in the cylinder group.

The inode list 61 stores an array of inodes, and as many files as the number of inodes stored therein can be created in the cylinder group block. Each i-node stores the attributes of each file such as the file type (normal file or directory file), the size of the file, and address information to the data block. Figure 7
An example of the inode stored in the inode list 61 is shown in FIG. In FIG. A, since the file type is [D], it can be seen that it is a directory file. Further, in FIG. 9B, since the file type is [-], it can be seen that it is a normal file. The substance of the file can be known from the area managing the substance of the file and the size of the file.

Returning to FIG. 6, the data block 63 stores the substance of normal files and directory files. The actual data of the file is stored in the substance of the normal file as shown in FIG.

An example of the substance of the directory file is shown in FIG.
A, FIG. 9C, and FIG. 9E are shown. The substantial part of the directory file stores the inode number of the directory file, the inode number of the parent directory file of the directory file, and the inode number and file name of the file managed by the directory file. .. The files mentioned here include directory files.

For example, FIG. 9A shows a root directory. In the figure, the inode number corresponding to the file name [.] Is the inode number of the directory file. That is, the inode number of the root directory is 2
Is. The inode number corresponding to the file name [...] In the column below is the inode number of the parent directory file of the root directory. In the root directory,
Since the parent directory file does not exist, the same inode number 2 is given as the parent directory file. The files under the root directory are stored in the lower column. The file [usr1] has an inode number of 3, the file [usr2] has an inode number of 4, and the file [usr3] has an inode number. Is 5, file [usr4]
It can be seen that the inode number of is 6.

Next, in the file system having a tree structure as shown in FIG. 11, the file [/ usr3 / jun / car.
The procedure for accessing [c] will be described. As described above, the substance of the root directory has the structure shown in FIG. 9A, and it can be seen that the inode number of the file [/ usr3] is 5. The inode with inode number 5 is shown in FIG. 9B. In the figure, since the file type is [D], it can be seen that [/ usr3] is a directory file. Further, looking at the area or the like that manages the entity, the entity of the directory file [/ usr3] can be seen as shown in FIG. 9C.

By looking at the substance of the directory file [/ usr3], the inode number of the file [jun] is 7
I understand. The inode with inode number 7 is shown in FIG. 9D. In the figure, since the file type is [D], it can be seen that [/ jun] is a directory file. Furthermore, if you look at the areas that manage that entity,
As shown in FIG. 9E, the substance of the directory file [/ jun] can be understood.

By looking at the substance of the directory file [/ jun], the inode number of the file [car.c] is 1
It turns out to be 1. The inode with the inode number 11 is shown in FIG.
Shown in F. The contents of the file [/usr3/jun/car.c] can be found by looking at the area that manages the entity.
In this way, the file [/usr3/jun/car.c] can be accessed.

By the way, for existing entities,
If the files can be accessed with different file names, there is no need to have multiple files with the same contents, and the data area of the file system can be saved. Further, the data can be unified. For example, if a reference file is moved to another directory file and can be accessed with a different file name, there is no need to rewrite the execution program that has accessed the entity with that file name. Also, when referring to a file managed by another person, in order to access that file with a file name other than that set by another person, copy the target file to its own directory file with the file name to be accessed. Although it is necessary, this wastes the copying time and requires the data area.

Therefore, link processing is performed. Link processing includes hard links and symbolic links. First, the method of hard linking will be described. The hard link performs a link process between files and is set by the following [In] command in this file system.

% Ln /usr3/jun/car.c / usr1 / tmp / ac (1) When such a command is executed, as shown in FIG. 10A, the file [/ usr3 / jun / car / The file [/ usr1 / tmp / ac] having the same inode number as that of .c] is added to the substance of the directory file [/ usr1 / tmp].

In the figure, the file name [ac] of the inode number 11 is added. Here, as shown in FIG. 9E, the inode number of the file [/usr3/jun/car.c] is 11. Since the files having the same inode number have the same entity, as shown in FIG. 11, the file [/usr3/jun/car.c] has a file [/ usr1 / t
mp / ac] to access. The number of hard links stored in the substance of the file [/usr3/jun/car.c] shown in FIG. 8 is increased by 1 to 2.

By thus performing the hard link, the stored data can be unified and the data area of the file system can be saved.

On the other hand, there is a symbolic link that can perform link processing between directory files as well as a hard link that can perform link processing only between files. The symbolic link links the directory files by adding the path name of the link destination directory file to the link source directory file. Symbolic links are set by the following [In-s] command.

% Ln -s / usr3 / jun / usr1 (2) When such a command is executed, as shown in FIG. 10B, a file in which the information of the symbolic link is stored is created. Further, as shown in FIG. 7A, the inode number of the symbolic link is the directory file [/ usr
1] is stored in the inode. As a result, the path name of the link destination directory file is given to the link source directory file. That is, as shown in FIG. 12, the directory file [/ usr1] is given the directory file [/ usr3 / jun] which is the path destination.

Therefore, the file [/ usr1 / jun / car.
If you access c], the directory file [/ usr
1], the directory file [/ usr3 / jun] will be searched automatically even if there is no file with such a name.
File [/ usr1 / jun] in directory file [/ usr1]
/car.c] is processed as if it exists.

As described above, since the symbolic link can be processed between directory files, if a plurality of subdirectory files and files exist in the directory file, the link processing can be easily performed by one processing. ..

[0021]

However, in the link processing of the file management system as described above,
There were the following problems. Since the hard link performs the linking process by specifying the file name, the entire file structure can be grasped, but the linking process cannot be performed between the directory files.

Although the symbolic link can be linked between directory files, since the link processing is performed by adding the path name of the linked destination directory file, the linked source directory file is linked to the linked source. I don't know the directory file. Therefore, it is not easy to grasp the entire file structure.

It is an object of the present invention to solve the above problems and to provide a file management system capable of linking directory files and facilitating grasp of the entire file structure.

[0024]

A file management system according to claim 1 comprises one or more normal files and a plurality of directory files for managing the one or more normal file information. In a file management system that can perform link processing between files, the link source directory file is the real directory file, the link destination directory file is the imaginary directory file, and the search information of the imaginary directory file is stored in the real directory file. It is characterized by.

[0025]

In the file management system according to the first aspect, the search information of the imaginary directory file is stored in the real directory file. Therefore, the existence of an imaginary directory file can be known from the file or directory file managed by the real directory file.

[0026]

An embodiment of the present invention will be described with reference to the drawings. File management states in the tree-structured file system as shown in FIG. 3 are shown in FIGS. 2C, 2D, and 2E. First, in this file system, the file [/ u
[sr3 / jun / car.c] will be described. Looking at the substance of the root directory, the inode number of the file [usr3] managed by the root directory is searched. Next, by looking at the substance, the file managed by the directory file [usr3] and its inode number can be known as shown in FIG. 2C. File [ju
It is understood that the inode number of [n] is 7, and as shown in FIG.
You can see that the file [jun] is a directory file, address information, etc.

Further, by looking at the substance, the file managed by the directory file [jun] and its inode number can be known as shown in FIG. It can be seen that the inode number of the file [car.c] is 11.
Looking at the inode with inode number 11, the file [car.
c] is a normal file, and you can see address information. In this way, the file [/usr3/jun/car.c]
Can be accessed.

Next, referring to FIG. 4, a method for creating an imaginary directory file [/ usr1 / sum] using [/ usr3 / jun] as a real directory file in the tree structure file system as shown in FIG. I will explain. Such a link process between directory files is called a directory link. The directory link is set by the following [dirln] command in this embodiment.

% Dirln / usr3 / jun / usr1 / sum (3) When such a command is executed, it is determined whether or not the actual directory file as the link source exists (step S101 in FIG. 4). .. In this case, since the directory file [/ usr3 / jun] exists as shown in FIG. 3,
The process proceeds to step S102 in FIG. If the real directory file does not exist, the message "No real directory file exists" is displayed (step S10).
6), end.

In step S102, it is determined whether or not a file (including a directory file) having the same name as the name of the imaginary directory file which is the link destination already exists. In this case, the file [/ usr
1 / sum] does not exist, the process proceeds to step S103. If a file with the same name already exists, a message "a file with the same name already exists" is displayed (step S106), and the process ends.

In step S103, it is determined whether the imaginary directory file which is the link destination is a descendant of the real directory file which is the link source. in this case,
As shown in FIG. 3, since there is no descendant relationship, step S
Continue to 104. In the case of a descendant relationship, a message "Directory cannot be linked" is displayed (step S106), and the process ends.

As described above, in this embodiment, the directory link is prohibited when the virtual directory file which is the link destination is a descendant of the real directory file which is the link source. As a result, it is possible to prevent the occurrence of a state (loop state) in which the real directory file exists again below the real directory file.

In step S104, as shown in FIG. 2B, an inode having the same entity information as that of the real directory file which is the link source is newly created as the inode of the virtual directory file which is the link destination. In this case, the inode with the inode number 17 having the same substance information as the inode with the inode number 7 indicating the directory file [/ usr3 / jun] is created. Further, as shown in FIG. 2A, a file having a file name [sum] with an inode number 17 is added to the substance of the parent directory file of the imaginary directory file which is the link destination.

Returning to FIG. 4, in step S105,
The inode number of the imaginary directory file that is the link destination and the inode number of its parent directory file are added to the imaginary directory file list. In this case, i of the imaginary directory file [/ usr1 / sum]
The node number 17 and the i-node number 3 of its parent directory file [/ usr1] are added to the imaginary directory file list 29.

Thus, as shown in FIG. 1, [/ usr
3 / jun] as a real directory file, [/ usr1 / su
An imaginary directory file called m] is created. Similarly, one real directory file can be directory-linked with a plurality of imaginary directory files.

As described above, in the present embodiment, when directory linking is performed, an i-node having the same substance information as that of the real directory file of the link source is given to the virtual directory file of the link destination. .. Further, the inode number of the imaginary directory file and its file name are added to the substance of the parent directory file of the imaginary directory file that is the link destination. This enables link processing between directory files.

Also, the virtual directory file list 29
In addition, the i-node number of the imaginary directory file that is the link destination and the i-node number of the parent directory file are added. Therefore, the existence of an imaginary directory file can be known from the file or directory file managed by the real directory file.

Next, a method for deleting a directory-linked real directory file or imaginary directory file will be described with reference to FIGS. First,
A case of deleting the imaginary directory file [/ usr1 / sum] will be described. Virtual directory file deletion is set by the following [rmdir] command.

% Rmdir / usr1 / sum (4) When such a command is executed, it is determined whether or not the directory file to be deleted exists (step S201). In this case, as shown in FIG. 1, since the directory file [/ usr1 / sum] exists, the process proceeds to step S202. If the directory file to be deleted does not exist, the message "Directory file does not exist" is displayed (step S20).
9), end.

In step S202, it is determined whether the directory file to be deleted is an imaginary directory file. In this case, the directory file [/ usr1 / sum]
Directory from the root directory and referencing its entity, the directory file [/ usr1 / su
[m] is found to be an imaginary directory file, as shown in FIG. 2E, and the process proceeds to step S207 in FIG.

In step S207, the inode number of the imaginary directory file and the inode number of its parent directory file are deleted from the imaginary directory file list. In this case, the inode number 17 of [/ usr1 / sum] and the inode number 3 of [/ usr1] are deleted from the imaginary directory file list 29.

Next, the i-node table used by this deletion directory is released (step S206), and the process ends. In this case, the directory file [/ usr1 / su
The area used by the inode with the inode number 17 indicating [m] is released, and the process ends. In this way, when deleting an imaginary directory file, it may be deleted without any special processing.

Next, the actual directory file [/ usr3 /
[jun] will be described. Again,
It is set by the [rmdir] command as described above.

% Rmdir / usr3 / jun (5) When such a command is executed, it is determined whether or not the directory file to be deleted exists (step S201). In this case, since the directory file [/ usr3 / jun] exists as shown in FIG. 1, the process proceeds to step S202. If the directory file to be deleted does not exist, the message "Directory file does not exist" is displayed as described above (step S209), and the process ends.

In step S202, it is determined whether or not the directory file to be deleted is an imaginary directory file. In this case, the directory file [/ usr3 / jun] is traced from the root directory, and the directory file [/ usr3 / jun] is referenced by referring to the entity.
Is found to be a real directory file, as shown in FIG. 2E, the process proceeds to step S203.

In step S203, it is determined whether or not an imaginary directory file exists in the directory file to be deleted. In this case, the imaginary directory file [/ u
[sr1 / sum] exists, the process proceeds to step S208.

In step S208, if an imaginary directory file exists, the inode number of the real directory file and the inode number of its parent directory file are deleted. Further, the i-node number of the first directory file stored in the imaginary directory file list and the i-node number of its parent directory file are stored.
Let the node number be the inode number of the real directory file and the inode number of its parent directory file. That is, in this case, i of the real directory file
The node number is 17, the inode number of its parent directory file is 3, and there is no imaginary directory file.

Then, the inode table used by this deleted directory file is released (step S20).
6), end. In this case, the directory file [/ us
The area used by the inode with the inode number 7 indicating [r3 / jun] is released and the process ends.

In this way, when deleting a real directory file having an imaginary directory file, the first imaginary directory file ([/ usr1 / sum]) from the imaginary directory file list 29 is changed to the real directory file. , Files and directory files managed by the real directory file ([/ usr3 / jun]) to be deleted can be managed by the directory file ([/ usr1 / sum]) that has become a new real directory file. ..

If it is determined in step S203 that there is no imaginary directory file in the deleted directory file, the process proceeds to step S204. In step S204, it is determined whether a file or directory file managed by the directory file to be deleted exists (whether or not the directory file to be deleted is empty).

When the directory file to be deleted is empty, the area used by the substance of the directory file to be deleted is released. Further, the i-node table used in this deleted directory is released (step S206), and the process ends.

If the directory file to be deleted is not empty, a message "This directory file cannot be deleted" is displayed (step S21).
0), end. In this way, when deleting a real directory file, if the imaginary directory file does not exist and the directory file to be deleted is not empty, the directory file to be deleted cannot be deleted. There is no risk of accidentally deleting files or directory files managed by.

[0053]

According to the file management system of the first aspect, the directory file of the link source is the real directory file, the directory file of the link destination is the imaginary directory file, and the search information of the imaginary directory file is the real directory file. It is stored in a file. Therefore, the existence of an imaginary directory file can be known from the file or directory file managed by the real directory file. This makes it possible to provide a file management system that enables link processing between directory files and facilitates grasping the entire file structure.

[Brief description of drawings]

FIG. 1 is a diagram showing a tree structure when directory files are linked.

FIG. 2 is a diagram showing a structure of a file management system.

FIG. 3 is a diagram showing a tree structure before linking directory files.

FIG. 4 is a flowchart of directory linking.

FIG. 5 is a flowchart for canceling a link of a directory file.

FIG. 6 is a diagram showing a file system in a conventional file management system.

FIG. 7 is a diagram showing an example of an inode.

FIG. 8 is a diagram showing the contents of a normal file.

FIG. 9 is a diagram showing an entity of a directory file and an inode.

FIG. 10 is a diagram showing an entity of a directory file.

FIG. 11 is a diagram showing a tree structure when a normal file is hard-linked.

FIG. 12 is a diagram showing a tree structure when a directory file is symbolically linked.

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Fujiki Fujii 10 Ouron Co., Ltd.

Claims (1)

[Claims] 1. A file management system comprising one or more normal files and a plurality of directory files for managing the information of one or more normal files, wherein the file management system is capable of linking directory files. A file management system characterized in that the original directory file is a real directory file, the linked directory file is an imaginary directory file, and the search information of the imaginary directory file is stored in the real directory file.