JP2003015924A - File management method - Google Patents

Abstract

(57) [Problem] To provide a file management system capable of easily detecting that a file has been updated by another driver or application without adding a special field to the file. SOLUTION: Information that is always updated when a file is updated is written as backup information in a field where free writing is permitted, and the information that is always updated when the file is updated is compared with the backup information. This makes it easy to detect whether or not the file has been updated.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a file management method for managing a file composed of data and the management information by using management information including information that is always updated when the file is updated. The present invention relates to a file management method capable of easily detecting whether a file has been updated.

[0002]

2. Description of the Related Art A logical file system is generally used to record data on a disk medium for various purposes such as PC (personal computer) use and AV (audiovisual) use. By using the logical file system, recorded data can be managed as a file and a directory hierarchy can be constructed, which facilitates management. Examples of the logical file system include the widely used FAT system and UDF (Universal Disk Format) introduced in DVD and the like.

The logical file system is such that, for data recorded on a disc, information for identifying the data, position information on the disc where the data is recorded, and the like are recorded on the disc as management information, and the information is recorded. It is a mechanism that enables data access by accessing the.

For example, the management information of the logical file system includes a file name, attribute information such as the creation date and time of the file, file size, information indicating the state, and position information on the disk in which the corresponding actual data is recorded. Is recorded.

There are various kinds of logical file systems such as FAT and UDF. However, these differ only in the structure of management information and the attribute information to be managed, and the file name or similar information is converted into the target data on the disk. In the sense that they can be accessed, they serve the same purpose.

Here, an example of a conventional general file system will be described with respect to the UDF which is also used for a DVD and the like. Files and directories are recorded on the disc, and a tree structure is formed based on the root directory. The UDF file system manages the disk by dividing it into an area for recording volume information and a partition area, and files and directories are recorded in the partition area.

On the disk, a logical sector number (LSN: Logical Sector Numbe) is assigned to the entire disk.
Two pieces of address information, that is, r) and a logical block number (LBN: Logical Block Number) allocated in the partition are added.

The structures of files and directories are shown in FIGS. 14 and 15, respectively. 14 and 15 are image diagrams on a disk in a partition, in which logical block numbers are added from left to right. When reading the management information and data from the disk, this logical block number is specified and read.

The data is FE (File
The recording position is managed by an AD (Allocation Descriptor) in the Entry. FE in FIG. 16 and FIG.
The structural standard of AD is shown. Descriptor Tag at the beginning of FE
Is recorded. The Descriptor Tag will be described later.

A description about the file structure is recorded in the ICB Tag, a user ID and a group ID are recorded in Uid and Gid, and a file permission is recorded in Permission. The File Link Count records the number of files and directories referenced by this FE.

Record Format, Record Display Attribut
e and Record Length are fields for record recording and are not used in the current UDF. AD for Information Length
Logical Bloc, the total size of data that is the area managed by
In k Recorded, the total number of logical blocks of data, which is an area managed by AD, is recorded.

Access Date and Time, Modification Dat
The last access time, last update time, and last attribute change time are recorded in e and Time and Attribute Date and Time. Checkpoint is always recorded as 1 in the current UDF,
not being used. Extended Attribute ICB and Extend
ed Attributes is a field for extended attributes, Implementat
The ion identifier is a field in which identification information for the system can be described, and the Unique ID is given a unique number to each FE.

The size of the Extended Attribute field is
Recorded in Length of Extended Attributes. Allocat
ion Descriptors is a field for recording AD, and Lengt
The size is recorded in h of Allocation Descriptors.
In FE for file, AD records one continuous area on the disc on which data is recorded, and uses Extent Length and Exte
It consists of nt Position.

The Extent Length is composed of a 2-bit type and a 30-bit value shown in FIG. As for the 2-bit type, there are four types shown in FIG.
Normally set to 0. The length of the area is recorded in bytes in 30 bits, and the start LBN of the area is recorded in the Extent Position. A plurality of ADs can be recorded in the FE, and the divided and recorded files can be centrally managed.

The directory is similarly managed by FE. The AD in the FE for the directory is FID (File Iden
It manages the recording position of a set of tifier descriptors.
However, the head FID manages the recording position of the parent directory, and the arrow is omitted in the drawings of this document. 20 and 21 show an FID and an IC included in the FID.
The structural standard of B (Information Control Block) is shown. F
The Descriptor Tag is also recorded at the beginning of the ID. File V
ersion Number, file version number, File Characteristic
Attribute information is recorded in s.

Length of File Identifier is File Identi
Size of fier field, Length of Implementation
Use records the size of the Implementation Use field. The Implementation Use field is a recording area for the system, and the file identifier or the directory name is recorded in the File Identifier field.

ICB is information for managing the recording position of the FE area, and includes Extent Length, Extent Location, Flags, UDF U.
It consists of a nique ID. Extent Length is the size of the area in bytes, Extent Location is the start LBN of the area, and Flags is a field for the area management attribute.
DF Unique ID is the same as the FE that is the reference destination of the FID Unique I
D is recorded.

FIG. 22 shows the structure standard of the Descriptor Tag. The tag type is recorded as a number in the Tag Identifier.
Descriptor Version is the version number, Tag Checksum is Desc
The value for the checksum of riptorTag is recorded. Tag Ser
The ial number has a serial number that is assigned each time it is formatted.

Descriptor CRC is the Descriptor C after the tag.
For the data of the length specified by RC Length, CRC (C
The value for yclic Redundancy Check) is recorded. CRC
Is a cyclic redundancy check, which is an error check for reading and writing data that is often used in disk controllers and the like. In Tag Location, the recording position (LBN) of this descriptor itself is recorded.

Here, a file writing procedure and a file reading procedure in the UDF file system will be described with reference to FIG. First, as shown in FIG. 23, data is written to the disc. When the writing of data is completed, F that manages the position information of the recording area, etc.
Write E to disk. The position information of the data recording area is recorded in the AD included in the FE.

Further, an FID for managing the file name SHRP0001.MQT and the recording position of this FE is created.
The recording position of this FE is recorded in the ICB included in the FID. The created FID is added to the FID column managed by the FE of the directory MQ # ROOT that creates SHRP0001.MQT.

Next, the procedure for reading a file will be described. For example, to read the created \ MQ # ROOT \ SHRP0001.DAT, the FE in the ROOT directory is first read from the disc, and the position in which the FID string managed by this FE is recorded is grasped from the AD in the FE. The FID string is read from the disc based on this information. Read F
F including the directory name MQ # ROOT from the ID column
Extract the ID.

The recording position of the FE in the MQ_ROOT directory is grasped from the ICB in the extracted FID and read from the disc. Similarly, extract the FID corresponding to SHRP0001.MQT from the FID column managed by the FE in the MQ # ROOT directory,
This reads the FE from the disc. Read F
Since the recording position of the substance of the target file SHRP0001.MQT is recorded in AD in E, it is possible to read from the disc based on this information.

[0024]

[Problems to be Solved by the Invention] Here, FE's Implem
Pay attention to the entation Identifier. Normally, in this field, identification information indicating which file system driver has edited the field is recorded. Using this information, you can see which driver was the last time the file was updated. However, when accessed by a driver that does not update this field, there is a problem that it is not guaranteed which driver is the last update.

Further, in a data format such as an HTML file, a file created by an application such as an HTML editor may record information for identifying the editor as header information or a comment. However, for the created file, another HTML
Header information may not be rewritten even if edited with an editor. Also, it is fully possible that comments are left as they are. As a result, similarly to the above, there is a problem in that the last edited application cannot be specified.

The present invention has been made in view of the above problems, and is a file accessed by a specific file system driver or application for the first time, or a previously accessed file is updated. The present invention provides a file management system capable of easily determining whether the file is a file that has been accessed before.

[0027]

A first invention of the present application is a file management method for managing a file composed of data and the management information by using management information including information that is always updated when the file is updated. In the above, in the management information, in the field in which free writing is permitted, the information which is always updated when the file is updated is written as backup information.

A second invention of the present application is a file management method for managing a file composed of data and the management information by using management information including information that is always updated when the file is updated. It is characterized in that information that is always updated when the file is updated is written as backup information in a field in which free writing is permitted.

A third invention of the present application is a file management method for managing a file composed of data and the management information by using management information including information that is always updated when the file is updated. In the above, the information that is always updated when the file is updated is written as backup information in association with the file name.

The fourth invention of the present application is characterized in that the presence or absence of the update of the file is detected by comparing the information that is always updated when the file is updated with the backup information.

[0031]

BEST MODE FOR CARRYING OUT THE INVENTION A first embodiment of the present invention, which detects a change in FE Information Length in UDF, will be described in detail below with reference to FIGS.

That is, in the present embodiment, the information that is always updated when the file is updated is written as backup information in the field in the management information where free writing is permitted.

First, the procedure for updating a file with the UDF driver to which this embodiment is applied will be described with reference to the flowchart of FIG. First, a normal file update process is performed (step 101). However, Impleme performed later
The ntation Identifier and Descriptor Tag are not written at this point.

Next, the Information Length is read (step 102) and the information is recorded in the Implementation Identifier (step 103). Finally, the Descriptor Tag is edited and recorded (step 104).

The format of the Implementation Identifier field will be described with reference to FIG.
In the UDF standard, the Implementation Identifier is Entity
Recorded in the Identifier format. Of which Iden
Since the Developer ID can be recorded in the tifier field, it will be recorded as "SHARP-UDF" here.

Since the Implementation Use field can be freely defined, the Backup Identifier is set in the previous 2 bytes.
Specifies the type of backup information. Here, "IL" is recorded as a value indicating Information Length. The last 4 bytes are defined as Backup Value and backup information is recorded. Information Length here
The lower 4 bytes of are recorded.

Next, consider a case where the file recorded in the above process is edited by a UDF driver to which this embodiment is not applied. First, if the amount of information changes as a result of editing, the Information Length is updated. Also,
If the driver rewrites the Implementation Identifier, another Developer ID is recorded. Here, Deve
"OTHER" shall be recorded as the loper ID.

A procedure for detecting the presence / absence of an update when the UDF driver to which the present embodiment is applied to the file re-edited in the above process will be described with reference to the flowchart of FIG. First, read the FE of the target file (step 201) and implement ratio
Refer to n Identifier (step 202).

If the Developer ID written in the Identifier field is not for this driver, that is, "OTHER" is recorded, it can be seen that the data has already been edited. Alternatively, the newly created file should have a different Developer ID (step 203).

When "SHARP" is recorded as the Developer ID, the Backup Identifier is recorded in the two bytes before the Implementation Use field. Backup Iden
The tifier is read to determine which information is backed up (step 204).

When "IL" is recorded in the Backup Identifier, the Information Length to be compared is read (step 205). If anything other than "IL" is recorded, it means that the management information has been rewritten,
This indicates that the data has been edited. Target is Informat
If it is the ion length, the lower 4 bytes of the information length are compared with the backup value (step 206). If the two values are different, it can be seen that the data has already been edited.

In this embodiment, Information Length is taken as an example of the information that is always updated when the file is updated, but other information such as Access Time or a combination of those information can be used. Needless to say, the same function can be realized by applying the invention to not only the UDF but also another file system having similar information.

Furthermore, the above-mentioned function of detecting editing by a driver other than the specific driver can be used in the situation as shown in FIG. In FIG. 4, the driver 101 to which this embodiment is applied has a file backup function or a file management information backup function.

First, the driver 101 to which this embodiment is applied
Then, the file A is created on a certain medium. Then, the driver 101 activates the backup creation circuit 102 and automatically creates a duplicate file A ′ of the file A.

Next, the medium is accessed by the driver 103 to which this embodiment is not applied. Where the driver 103
To edit file A and rewrite it to file B. Then, a mismatch occurs between the file B and the duplicate file A ′.

Then, the medium is again accessed by the driver 101 to which this embodiment is applied. Then, the update detection circuit 104 of the driver 101 operates to detect that the file has been updated. With that as a trigger, the backup update circuit 105 is activated to automatically update the duplicate file A ′ to the duplicate file B ′.

As described above, for the purpose of backup, it is possible to detect the update of the file by comparing the target file and the duplicate file, but it is necessary to alternately access the file, which is effective. Is not good. On the other hand, according to the present embodiment, since only the FE of the target file is accessed, it is possible to detect the presence / absence of file update at high speed.

As described above in detail, in the present embodiment, whether or not the file has been updated can be easily detected not only for the purpose of backup but also for other purposes. Another useful feature is that it is not necessary to add a special field as file management information.

Next, as a second embodiment of the present invention, H
What detects the update of the last update time of the HTML file by the TML editor will be described in detail with reference to FIGS.

That is, in this embodiment, the information that is always updated when the file is updated is written as backup information in the field in the data where free writing is permitted.

First, the procedure for updating the HTML file with the HTML editor to which this embodiment is applied will be described with reference to the flowchart of FIG. First, normal HTML editing is performed (step 301). At the time of saving, the editor information and the saving time are recorded using the comment tag (step 302), and the file is closed (step 303).

At this time, the save time and the file last update time must have the same value. In the present embodiment, considering the allowable range of the error, the storage time is a value obtained by truncating the information of seconds or less.

FIG. 6 shows an example of recording comment tags. In this example, "SHARP # BACKUP # INF" is included in the HTML header information.
The identification information "O" and this HTML file
Information indicating that editing is completed at 15:05 on the 26th of the month is recorded.

Next, consider a case where the HTML file recorded in the above process is edited by an HTML editor to which this embodiment is not applied. First, as a result of editing,
The last modified time of the file is updated. There may be an editor that deletes the comment tag during the editing process.

The HTML re-edited in the above process
Regarding the procedure for detecting the presence or absence of update when a file is accessed again by the editor to which this embodiment is applied,
Description will be made with reference to the flowchart of FIG. 7. First, the target HTML file is read (step 401) and the comment tag is extracted (step 402).

Next, from the contents of the comment, the above-mentioned "SHARP # B
Search for the description of ACKUP # INFO: "(step 403). If it is not detected, H edited in the above re-editing process is searched.
It can be determined that the file is a TML file or a newly created HTML file.

If it is detected, the last update time of the file is read (step 404), the save time is read from the comment tag and compared (step 405). If it is different from the last update time of the file, it can be judged that the file was edited in the re-editing process.

The file management method as described above is used in HTML.
By implementing it in the editor, it becomes possible to easily detect the presence or absence of update without defining a special field for detecting file update in the HTML standard.

In the present embodiment, the last update time has been described as an example of the information that is always updated when the file is updated, but other information such as the file size and a combination of those information can be used. .

Not only the HTML file but also a PDF file or a J file as long as the file has a field for recording additional information like the comment tag of this embodiment.
Even when applied to PEG files, MIDI files, etc.
It goes without saying that the same function can be realized.

Next, as a third embodiment of the present invention, U
What detects a change in the FE Descriptor CRC in the DF will be described in detail with reference to FIGS. 8 to 10.

That is, in the present embodiment, the information that is always updated when a file is updated is written in a predetermined file in association with a file name. Here, the update is checked. Prepare a backup file for update check that retains the previous status of the target file.

First, the procedure for updating a file with the UDF driver to which this embodiment is applied will be described with reference to the flowchart of FIG. First, a normal file update process is performed (step 501). Here, the first
Unlike the embodiment described above, the Implementation Identifier and Des
We will also update the criptor Tag.

Next, the value of the Descriptor CRC is read (step 502) and the backup file for update check "bac
Open "kup.inf" (step 503) and enter the full path file name and CRC of the file being edited in the backup file.
The correspondence of is recorded (step 504). If the same file is already recorded, update it.

A description example of the backup file is shown in FIG.
Shown in. Here, the hexadecimal 2-byte CRC data and the full path name of the file are recorded in association with each other.

Next, consider a case where the file recorded in the above process is edited by a UDF driver to which this embodiment is not applied. If you edit the file, the values recorded in the FE will be updated respectively and the Descriptor C
RC also has a different value.

A procedure for detecting an update when the driver to which the embodiment is applied again accesses the file re-edited in the above process will be described with reference to the flowchart of FIG. First, read the backup file "backup.inf" when the medium is mounted
(Step 601).

It is determined whether the file to be accessed is included in the list recorded in the backup file (step 602). If it is not included, it is determined that the file is newly created, and reading of the file is started (step 603).

Even if it is included, the reading of the file is started (step 604) and the Desc recorded in the CRC and FE Descriptor Tag recorded in the backup file.
Compare with riptor CRC (step 605). If the two values are different, it indicates that the FE holds information different from the previous one, and it can be determined that the file has been updated.

In the present embodiment, the Descriptor CRC has been described as an example of the information that is always updated when the file is updated, but the Info as shown in the first embodiment is used.
It is also possible to use rmation Length or Access Time. Also, the whole Descriptor Tag or a combination of these elements is possible.

Furthermore, in the present embodiment, an example in which the file is recorded in a file format called a backup file has been shown, but the logical format may be expanded and the file may be recorded in a format different from the file.

In the first embodiment, the CRC calculation target is
Since there is an Implementation Use field, it cannot be written in the Implementation Use field after the CRC calculation. On the other hand, in the present embodiment, after the CRC calculation, the backup of the CRC is recorded in the backup file "backup.inf" as the information of the identification target.
It is possible to apply information such as CRC that could not be implemented in the above embodiment to the information to be identified. Also, the first
The present embodiment is effective even when a field corresponding to the Implementation Use field of the above embodiment is not prepared.

Next, as a fourth embodiment of the present invention, as in the second embodiment, the H
A method for detecting the update of the last update time of the TML file will be described in detail with reference to FIGS. 11 to 13.

That is, in the present embodiment, the information that is always updated when the file is updated is written in a predetermined file in association with the file name. Here, the update is checked. Prepare a backup file for update check that retains the previous status of the target file.

First, the procedure for updating the HTML file with the HTML editor to which this embodiment is applied will be described with reference to the flowchart of FIG. First,
Perform normal HTML edit and save (step 7
01). Next, the last update time of the file is read (step 702), and the update check backup file "backup.
Open inf "(step 703).

Further, the full path file name of the updated file and the last updated time read out are registered (step 7
04). If the same file is already recorded, update it.

A description example of the backup file is shown in FIG.
2 shows. Here, the last update date and time of each file is associated with the full path name of the file.

Next, when the HTML file recorded in the above process is edited by an HTML editor to which this embodiment is not applied, the last update time of the file is updated.

The HTML re-edited in the above process
A procedure for detecting an update when a file is accessed by an editor to which the present embodiment is applied will be described with the flowchart of FIG. First, when the medium is mounted, the backup file "backup.inf" is read (step 801).

Then, it is determined whether the HTML file to be accessed is included in the list recorded in the backup file (step 802). If it is not included, it is judged that it was newly created and HTM
The reading of the L file is started (step 803).

Even when the HTML file to be accessed is included in the list, the reading of the HTML file is started (step 804), and the last update time recorded in the backup file and the last recorded in the file management information are recorded. The update time is compared (step 805). When the two values are different, it indicates that the management information of the HTML file holds information different from the previous one, and it can be determined that the file has been updated.

In the present embodiment, it is not necessary to consider the time error due to the operation of the system as in the second embodiment.
Also, the HTML standard allows easy addition of comments, but when there is not enough area for recording backup information due to the limited size of fields,
This embodiment is effective when it is desired to save the trouble of analyzing the TML tag.

In the present embodiment, the last update time is described as an example of the information that is always updated when the file is updated, but other information such as the file size and a combination of those information can be applied. is there. Not only HTML files but also PDF files and JP
Needless to say, the same function can be realized by applying it to EG files, MIDI files, etc.

[0084]

According to the file management method of the present invention, the information that is always updated when a file is updated is written as backup information in a field in which free writing is permitted without adding a special field. Whether or not the file is updated can be easily detected by comparing the information that is always updated when the file is updated with the backup information.

Even if there is no field in which free writing is permitted as described above, the information that is always updated when the file is updated is used as backup information in association with a file name and a predetermined value of 1 is set. By writing in the file, it becomes possible to easily detect whether or not the file has been updated.

[Brief description of drawings]

FIG. 1 is a flowchart showing a file update procedure according to a first embodiment of the present invention.

FIG. 2 Implementati in the first embodiment of the present invention
It is explanatory drawing which shows on Identifier.

FIG. 3 is a flowchart showing a file update detection procedure according to the first embodiment of the present invention.

FIG. 4 is an explanatory diagram showing a case where the first embodiment of the present invention is used for a backup function.

FIG. 5 is a flowchart showing a file update procedure according to the second embodiment of the present invention.

FIG. 6 is an explanatory diagram showing a recording example of backup information according to the second embodiment of the present invention.

FIG. 7 is a flowchart showing a file update detection procedure according to the second embodiment of the present invention.

FIG. 8 is a flowchart showing a file update procedure according to the third embodiment of the present invention.

FIG. 9 is an explanatory diagram showing a recording example of a backup file according to the third embodiment of the present invention.

FIG. 10 is a flowchart showing a file update detection procedure according to the third embodiment of the present invention.

FIG. 11 is a flowchart showing a file update procedure according to the fourth embodiment of the present invention.

FIG. 12 is an explanatory diagram showing a recording example of a backup file according to the fourth embodiment of the present invention.

FIG. 13 is a flowchart showing a file update detection procedure according to the fourth embodiment of the present invention.

FIG. 14 is an explanatory diagram showing a file recording method in the UDF file system.

FIG. 15 is an explanatory diagram showing a directory recording method in the UDF file system.

FIG. 16 is an explanatory diagram showing File Entry.

FIG. 17 is an explanatory diagram showing an Allocation Descriptor.

FIG. 18 is an explanatory diagram showing a format of Extent Length.

FIG. 19 is an explanatory diagram showing Type of the Extent.

FIG. 20 is an explanatory diagram showing a File Identifier Descriptor.

FIG. 21 is an explanatory diagram showing an Information Control Block.

FIG. 22 is an explanatory diagram showing a Descriptor Tag.

FIG. 23 is an explanatory diagram showing a recording example in the UDF file system.

[Explanation of symbols]

101 driver 102 Backup creation circuit 103 driver 104 Update detection circuit 105 Backup update circuit

   ─────────────────────────────────────────────────── ─── Continued front page    (72) Inventor Takayoshi Yamaguchi             22-22 Nagaikecho, Abeno-ku, Osaka-shi, Osaka             Inside the company F-term (reference) 5B082 DE06 EA01 GA14                 5D110 AA17 DA01 DA06 DA11 DA15                       DA17 DB03 DC05 DC16 DC28

Claims (4)

[Claims] 1. A file management method for managing a file composed of data and the management information by using management information including information that is always updated when the file is updated, and free writing in the management information is permitted. A file management method characterized in that information updated without fail when the file is updated is written as backup information in the specified field. 2. A file management method for managing a file composed of data and the management information by using management information including information that is always updated when the file is updated, and free writing in the data is permitted. In the file management method, the information that is updated when the file is updated is written as backup information in the field. 3. A file management method for managing a file composed of data and the management information by using management information including information that is always updated when the file is updated. The file management method is characterized in that the information that is always updated when is updated is written as backup information in association with the file name. 4. The file management method according to claim 1, wherein whether or not a file has been updated is detected by comparing information that is always updated when updating the file with the backup information. A file management method characterized by: