Imagination of a file directory structure Fishcat original
1. The existing file system is not enough, we know that since the birth of the operating system, the file system has experienced a lot of types, which is the most extensive use of DOS's FAT and Windows FAT32 and WindowNT NTFS, which is a common feature of these file systems. When the file is completely hierarchical, when accessing a file, you need to start a layer of entry from the root directory, which is inconvenient from the user's perspective. If a user created a file1.txt placed in C: / Windows / Profiles / All Users / under, he has to open such a multi-layer directory to access his file. This is not required for the easy operation required by the modern operating system. In fact, the designer of the operating system has no reason to force the user to remember that the path to a file is stored, and most of the work should make the computer to complete. Especially the unique file, the system should make it immediately to submit this file immediately as long as the user gives the file name. This reality requires a difficulty of completing the existing file directory structure, and it is possible, just like the finding file. In that case, everyone knows that it takes time, basically can't meet the needs of users. So we need to redesign a new file system structure that needs to be inherited to inherit the advantages of the previous file system. 2. Directory area based on file ID (file allocation table)
To do transparency to the user's file and path, you must express it in the directory area. The basic idea of a directory area based on the file ID is an important information such as a file name. To be a simplest example, in the directory area we save only the Hash value of the file name (ie, file ID) and file start cluster information. By trying to avoid conflictous Hash operations to generate the ID corresponding to the ID, as for other information we can save inside the file. The contents of the file are also changing, plus the file control information on the head of the content (eg File name, directory ID, date, size, etc.) and custom information (like XML, free expand), display files when the file is displayed on the user interface, but as control information is displayed in resources Manager in the manager. Now let's consider the problem of getting file1.txt mentioned in the previous steps, completing a few steps: 1. The file system management program converts file1.txt into a number n; 2. Find this number in the file allocation table Since each of our directory records, only the values of the two domains, so this directory area is very small, finding very quickly; because the result of Hash is not possible to avoid conflicts, the results of the lookup may not be unique. III. Read out the content of the lookup results file Get the real name of the file, get file1.txt; if there is more than one result, there is a different name file in other directories, ask the user's exact needs; four. Submit to the user, complete the operation. From the above, it can be seen, The complex problem of file system catalog hierarchy based on file ID, which is largely convenient for users to operate, improve users' work efficiency. At the same time, there is an extra benefit: I. improve find Speed. There are two reasons, one is that the file directory area is greatly reduced, reduces the burden on the disk; the second is to match the matching of the file name string, but a simple number comparison. 2: By putting the file The control information is placed inside the file, and stores with the XML format, the system and the user can have a complete flexibility to modify the control information of the file, and personalize the file. III. File name length, file size, etc. Not restricted. Because we are putting the control information of the file in the file content, the file name can be arbitrarily, and it will not waste disk space. File size can not be restricted. IV. Suitable search. File control information with XML Format storage, applications or users can join the keywords such as files in the file, with XML's considerations of search are the same.
These are just a probably contour, which may have some additional problems in the specific implementation, then leave others. 2002-8-26