JP2007179436A - Information processor, information processing method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To achieve the efficiency of processing for restoring matching about a file management state by a file system and a file management state by a management file. <P>SOLUTION: Firstly, as a file stored in a storage medium by a file system, a content file is also managed by a management file. Then, a backup file for this management file is prepared. Furthermore, state information showing a state relating to matching between the file system and the management file about the management state of the content file is prepared. Then, this state information is rewritten according to the progress of processing to update file system management information and the management file according to such an operation as the additional recording and the deletion of the content file. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to an information processing apparatus that executes writing and reading of information with respect to a storage medium, and a method thereof. The present invention also relates to a program to be executed by such an information processing apparatus.

In managing data stored in various storage media such as an HDD (hard disk), a file system is widely used and managed in units of files. As such a file system format, for example, FAT, HFS (Hierarchical File System) and the like are known.
By interposing such a file system between, for example, an application and a driver of the storage medium, for example, the application can perform an operation (file read / write) without being aware of the physical data storage structure of the storage medium. Operation).

  In recent years, many types of storage media tend to have a large capacity due to a decrease in the bit unit price and an increase in recording density. At the same time, the speed of various information processing is also increasing. Against this backdrop, it has become possible to store data files (content files) formed by a large number of contents such as still images, moving images, and audio on a storage medium.

As a device that records and reproduces content such as still images, moving images, and audio, there are digital still cameras, video camera devices, and the like in the present situation. When a large number of content files can be stored in a storage medium, for example, ease of searching and browsing, enrichment of attached information, and the like become important for users.
Since the file system is originally intended to manage data stored in the storage medium in units of files as described above, the file related information defined in the file system is file It is limited to basic information such as name (and extension), file size, creation date and time, and update date and time. In addition, since it is basically employed in various storage media such as HDDs, it has poor expandability for such attached information.

  Therefore, a file system having information for exclusive management of content files stored in the storage medium after management of all files stored in the storage medium by the file system is performed. The use of management information (management files) has been proposed and is being implemented.

JP 2004-227630 A

However, the management file and the management information (file system management information) used by the file system are independent and independent information units. For this reason, for example, when a failure occurs such as when the power is shut down when either one of the management file and the file system management information is being rewritten, the file management content by the file system, There will be some inconsistency with the file management contents of the management file. In a state where such an inconsistency occurs, normal content file management cannot be expected thereafter.
Therefore, as an invention of the present application, even if the management file and the file system management information are inconsistent as described above, it is possible to return to the consistent state. It is another object of the present invention to make such a process for recovery more efficient.

In view of the above-described problems, the present invention is configured as an information processing apparatus as follows.
In other words, by using basic file management means for managing files stored in the storage medium and specific file management information managed in units of files by the basic file management means, identification in the file managed by the basic file management means Specific file management means for managing types of files, and basic file management means that are managed on a file-by-file basis and have information contents that reflect the contents of the specific file management information for backup of the specific file management information To change the file management contents by the basic file management means and rewrite the specific file management information and the backup file according to the processing related to the specific type of file, and the backup file processing means for processing the backup file to be processed In the prescribed procedure Update control means for controlling the processing to be executed by the basic file management means, the specific file management means, and the backup file processing means, the management content of the specific type of file by the basic file management means, and the specific file management information Status information to be stored in a predetermined non-volatile storage area and changed according to the progress of the procedure when update processing is being executed by the update control means Status information processing means.

In the above configuration, basic file management for all files stored in the storage medium is performed by the basic file management means. In addition, among these files, specific types of files are managed by specific file management information. Further, a backup file is provided for the specific file management information. This backup file is provided for the purpose of backing up the specific file management information, and should have information contents reflecting the contents of the specific file management information.
When some processing (recording, playback, deletion, update, etc.) regarding a specific type of file is performed, the processing result is reflected so that the file management content can be changed by the basic file management means. The specific file management information and the rewriting (updating) of the backup file are updated according to a predetermined processing procedure. At this time, according to the progress of the processing, the file management content by the basic file management means, The specific file management information and the contents of the backup file change sequentially. Therefore, in the present invention, the state transition of the contents changing in this way is described in the status information. This status information is stored in a nonvolatile storage area.
In the case of such a configuration, first, since the backup file of the specific file management information exists, in normalizing the specific file management information, the content file actually stored in the storage medium is read all at once. You can use the contents of the backup file instead of rebuilding with.
Furthermore, when the status information of the present invention is as described above, for example, when updating the basic file management information, the specific file management information, and the backup file according to the file operation of a specific type of file, Even if a failure such as a power shutdown occurs and processing is interrupted, and this information and file are inconsistent, the status information indicates that the inconsistency is estimated. be able to. Accordingly, the processing content adapted to the estimated state can be selected as the processing for restoring the consistency.

  In this way, the present invention provides consistency in the case where inconsistency occurs between a plurality of pieces of management information such as file management contents by the basic file management means (basic file management procedure) and specific file management information. It is possible to obtain an effect that the process for returning the process is performed more efficiently than before.

  Hereinafter, the best mode for carrying out the present invention (hereinafter referred to as an embodiment) will be described. In this embodiment, a case where the configuration of the information processing apparatus according to the present invention is applied to a digital video camera is taken as an example.

FIG. 1 is a block diagram illustrating a configuration example of a digital video camera 1 according to the present embodiment.
In the digital video camera 1 shown in this figure, the optical system unit 2 includes an imaging lens, a diaphragm, and the like, and forms incident light on the photoelectric conversion unit 3 as imaging light. Further, the optical system unit 2 includes a focus adjustment mechanism for focus adjustment, a diaphragm variable mechanism that varies the diaphragm according to the diaphragm value, and the like. Is performed by a drive signal output from the camera function unit 6. The camera function unit 6 is configured to output a required drive signal so as to obtain an appropriate focus state, aperture state, and the like, under the control of the CPU 10.
For example, when an optical zoom function is to be provided, a zoom mechanism for moving the zoom lens is provided in the optical system unit 2 and driving for moving the zoom mechanism in accordance with the control of the CPU 10 in the same manner as described above. What is necessary is just to provide a part. Further, the camera function unit 6 may be configured to provide a strobe light emission function after providing a strobe.

  The photoelectric conversion unit 3 includes, for example, a CCD (Charge Coupled Device) that is a photoelectric conversion element, a CMOS sensor, and the like, and photoelectrically converts imaging light incident from the optical system unit 2 and imaged on the light receiving surface. Thus, an imaging signal is generated and output to the video signal processing unit 4. At the time of shooting, for example, an instruction of a shutter speed determined according to the exposure setting result is notified from the CPU 10 to the video signal processing unit 4. The video signal processing unit 4 outputs a scanning timing signal corresponding to the notified shutter speed to the photoelectric conversion unit 3. The photoelectric conversion unit 3 performs scanning according to the scanning timing signal, executes photoelectric conversion processing, and outputs a video signal.

The video signal processing unit 4 performs waveform shaping on the analog video signal (captured image signal) input from the photoelectric conversion unit 3 by performing gain adjustment and sample hold processing, for example, and then performs A / D conversion. By doing so, it is converted into digital video signal data. Then, for the digital video signal obtained by this conversion process, for example, a process for generating display luminance data is performed, and a video signal process for displaying on the display unit 7 is executed. Accordingly, the video signal processing unit 4 can execute signal processing for so-called on-screen display so that a character image or the like can be displayed superimposed on the captured image under the control of the CPU 10.
The actual display device employed as the display unit 7 is not particularly limited, but currently, liquid crystal display panels are widely employed.

In addition, the video signal processing unit 4 performs, for example, compression encoding processing by a predetermined method on the digital video signal obtained by converting the analog video signal input from the photoelectric conversion unit 3 to generate compressed video data. Is possible.
The digital video camera of this embodiment also has a still camera function. That is, it is possible to generate a still image data file in a predetermined format as a photograph for the captured image signal. Such image processing is also performed by the video signal processing unit 4.

Further, the video signal processing unit 4 uses an image (video) signal input from the photoelectric conversion unit 3 or a file (AV file) of AV (Audio Video) data read from a medium described later in a predetermined format. It can be converted into an analog video signal or a digital video signal and output to an external device or the like via the image input / output unit 5.
The image input / output unit 5 can input a video signal of a predetermined system from the outside, and the input video signal can be displayed on the display unit 7 through the processing of the video signal processing unit 4. The video signal processing unit 4 converts the video signal input from the image input / output unit 5 into recording data and transfers the video signal to the media controller 13 in the same manner as the analog video signal input from the photoelectric conversion unit 3. You can also
Correspondingly, the image input / output unit 5 includes, for example, a video (image) signal output terminal / video signal input terminal according to a predetermined method.

In addition, the digital video camera 1 according to the present embodiment includes an audio processing unit 8 and an audio input / output unit 9 so that audio signals can be input / output.
First, for voice input, a microphone or the like is provided as the voice input / output unit 9, and external voices are collected and converted into voice signals to be inputted. The audio signal input in this manner is output to the audio processing unit 8. The audio processing unit 8 performs audio signal processing such as conversion into compressed audio data encoded by an audio compression encoding method corresponding to compression encoding of a captured image.

The CPU 10 forms an AV file of a predetermined format from the compressed video data for the captured image obtained by the video signal processing unit 4 and the compressed audio data for the collected sound obtained by the audio processing unit 8. Control processing is executed. In this AV file, the playback time axis of the sound output by reproducing the compressed audio data is synchronized with the moving image output by reproducing the compressed video data. The configuration for actually forming the AV file may be a software configuration for digital signal processing obtained by the CPU 10 executing the program, or hardware for forming the AV file. In addition, the CPU 10 may be configured to control the operation of the hardware.
The data as the AV file is transferred to the media controller 13 as recording data, for example, under the control of the CPU 10. The CPU 10 can also transfer a still image data file of a predetermined format as a photographic image generated by the video signal processing unit 4 to the media controller 13 as recording data.

  The audio input / output unit 9 may be configured to include an audio signal input terminal and the like to input an audio signal from an external audio device or the like. The audio processor 8 converts the audio signal input from the audio signal input terminal into a digital audio data file in a predetermined format. The CPU 10 can also transfer data of such a digital audio data file to the media controller 13 as recording data.

  The media controller 13 is configured to be able to execute control processing related to data processing corresponding to a predetermined medium (storage medium) in cooperation with the CPU 10. Data processing for media here refers to any processing related to data to be stored on the media, such as media formatting processing, file write / read processing for information on the storage area of the media, and file management. Say.

In the present embodiment, an example in which an HDD (hard disk) 14 is connected to the media controller 13 is shown. The HDD is a storage device that includes a magnetic disk as a storage medium as is well known, and is currently one of the storage media with the lowest bit unit price and good recording density. Large capacity is obtained. As is well known, physical data is read / written from / to a magnetic disk as a storage medium by applying a magnetic field and detecting a magnetic field while tracing a track formed on the magnetic disk by a magnetic head. Realized.
In this case, the HDD 14 is fixedly incorporated in the digital video camera 1, for example. However, the digital video camera 1 (host) may be removable and may be removable according to a predetermined standard.

  As described above, the media controller 13 selects the recording data from the media (HDD 14) connected to the media controller 13 as the recording data is transferred. Transfer further to the media being used. In the medium to which the data has been transferred, the data is written and stored in the storage area in accordance with an instruction from the media controller 13 side. In this way, data stored in the medium is stored and managed as a file. Note that management of files stored on the media is performed by a predetermined file system.

For example, when playing back an AV file among files stored in a medium, the CPU 10 and the media controller 13 access and read the designated AV file. The AV file read in this way is separated into compressed video data and compressed audio data by processing of the CPU 10, for example, and the compressed video data is transferred to the video signal processing unit 4, and the compressed audio signal is processed by the audio processing unit. 8 is handed over.
In this case, the video signal processing unit 4 and the audio processing unit 8 respectively perform necessary reproduction signal processing including demodulation processing on the compressed video data and the compressed audio data transferred as described above. As a result, an image obtained by reproducing the compressed video data is displayed on the display unit 7, and the audio input / output unit 9 has an audio signal obtained by reproducing the compressed audio data in synchronization with the reproduction time of the image. Then, it can be output as audio by the speaker, or can be output from the headphone terminal.

  In addition, for example, an audio data file reproduced from a medium is output as a predetermined format audio signal and audio data to the outside via the audio input / output unit 9 after being subjected to the audio signal processing of the audio processing unit 8. It is also possible. In this case, the audio input / output unit 9 includes an audio output terminal corresponding to a format of a predetermined audio signal and audio data output from the audio processing unit 8.

A CPU (Central Processing Unit) 10 executes various control processes for the digital video camera 1 by executing a program. The ROM 11 stores various setting information used for the CPU 10 to execute processing in addition to various programs executed by the CPU 10. The RAM 12 is used as a work area when the CPU 10 executes processing according to a program, and holds data such as various arithmetic processing results.
The non-volatile memory 12a is formed of a memory element such as a flash memory that does not erase the stored contents even when the power supply is stopped, and data writing / reading is executed under the control of the CPU 10. The The data (information) to be stored in the nonvolatile memory 12a is generally setting information whose contents are appropriately changed, but is not particularly limited, and the actual specifications of the digital video camera 1 are not limited. It is sufficient to store various necessary information according to the above.

  In this case, the operation input unit 15 collectively indicates various operators provided in the digital video camera 1. For example, the operators in the operation input unit 15 include a shutter button operated at the time of taking a picture, an operator for selecting a shooting mode, an operator for increasing / decreasing parameters, and the like.

The communication unit 16 is a part configured by mounting hardware and software for communicating with an external device by a predetermined data communication method according to the control of the CPU 10. In practice, the communication unit 16 employs USB (Universal Serial Bus). In addition, the digital video camera 1 according to the present embodiment is assumed to be equipped with a USB mass storage class.
By supporting the USB mass storage class in this way, for example, when the digital video camera 1 of the present embodiment and an external information processing device such as a personal computer are connected by USB, the external information processing device side The HDD 14, which is the medium on the digital video camera 1, can be accessed as an external removable medium.

  Note that, under the present invention, the data communication method supported by the communication unit 16 is not particularly limited regardless of whether it is wired or wireless, and the number of corresponding data communication methods should also be limited. Not. At present, as a data communication method other than the above-mentioned USB, if it is wired, a network such as Ethernet (trademark), a data bus standard such as IEEE (the Institute of Electrical and Electronic Engineers) 1394 can be cited. . In the case of wireless, short-range wireless communication between devices such as Bluetooth (trademark) and wireless LAN (Local Area Network) standards such as IEEE802.11a / b / g can be cited.

  The power supply unit 17 supplies operating power to various hardware devices in the digital video camera 1 and includes, for example, a power supply circuit that operates by receiving power supply from a battery or a power adapter.

  As described above, in the digital video camera 1 of the present embodiment, an AV file as a moving image obtained by imaging / sound collection or a still image file as a photograph can be stored in the medium (HDD 14). It can be done.

  A file stored in a medium is normally managed by a file system having a predetermined format. In this embodiment, it is assumed that the file is managed by a FAT (File Allocation Table) file system. As is well known, the FAT file system manages files by a tree-type directory structure, and data writing / reading is performed by a logical minimum data management unit called a cluster. It is said that. A cluster is a unit obtained by collecting a predetermined number of sectors, which are the minimum units of physical data writing / reading on a medium.

  In this embodiment, among the files managed by the file system (FAT) and stored in the medium as described above, AV files (moving image files) and still image files such as photographs are played back. Differentiating from system-related types of files, for example, as being included in file types (types) called content files because the output information content (content) is meaningful to the user To do.

In addition, according to the present embodiment, as a file stored in the HDD 14, a content-specific management file (hereinafter simply referred to as a management file) having management information contents for specially managing the content file is included. It is said.
Further, in this embodiment, a backup file of the management file is also generated and stored in the HDD 14.

FIG. 2 shows a directory structure of the HDD 14 constructed by the FAT file system in the digital video camera 1 of the present embodiment.
As a directory structure in the HDD 14, for example, as shown in the figure, a management file directory, a still image directory, and a moving image directory are arranged immediately below the root directory.
Among these directories, the still image directory and the moving image directory are directories for storing content files. That is, one or more still image files such as photographs are stored in the still image directory. The moving image directory stores the moving image file as the AV file described above.
The management file directory stores a management file and a backup file of the management file. As will be described later, the management file according to the present embodiment is actually composed of a set of property files, thumbnail files, and metadata files, for example. The management file backup file includes backup files for property files and metadata files.

  The thumbnail file has a correspondingly large file size because it includes image data. For this reason, if the thumbnail file is not backed up, the storage capacity can be saved accordingly. In addition, if the management file and the file system are consistent, reconstruction (recovery) is possible at any time. For these reasons, the thumbnail file is not included in the backup file.

Of course, there is no need to consider especially the saving of storage capacity because the storage medium has a very large capacity, or it is better to back up the thumbnail file due to the system specifications etc. When priority is given, there is no particular problem with including a thumbnail file in the backup file.
Further, as a practical example of the present embodiment, the management file directory is set as an invisible directory in normal use. Therefore, the management file and backup file stored in this management file directory are also invisible files. Since these management files and backup files are files used by the system for content management, it is preferable to prevent the user from inadvertently deleting or rewriting the files, for example. Therefore, in the present embodiment, these files are managed as invisible files as described above.

FIG. 3 shows an example of the structure of the management file of this embodiment.
As described above, the management file is further divided into a property file, a thumbnail file, and a metadata file. In this embodiment, a set of the property file, thumbnail file, and metadata file is handled as a management file. Of these property files, thumbnail files, and metadata files, essential files are property files, and thumbnail files and metadata files are optional.

  As shown in the figure, the property file is formed as a set of a file header and one or more file entries (1 to n). Each file entry corresponds to the content file on a one-to-one basis, and stores basic information related to the corresponding content file. The structure of the entry file will be described later.

  A thumbnail file is formed with one or more thumbnail slots. In principle, one thumbnail slot stores thumbnail image data, which is a representative image indicating the corresponding content file, corresponding to one content file.

  The metadata file is composed of one or more metadata slots. One metadata slot should also correspond to one content file. In the title slot, for example, arbitrary information items such as data in text format (which can be used for comments) and information indicating grouping of content files can be stored.

The internal structure of the file header in the property file is not shown here, but for example, information indicating the creation date / time and update date / time of the current property file, information indicating the size of the file entry, and the file entry to be stored Information indicating the number, a thumbnail file list, a metadata file list, and the like are included.
The thumbnail file list stores information indicating the creation date and update date of the thumbnail file, information indicating the size of the thumbnail slot, information indicating the number of thumbnail slots stored, and the like.
The metadata file list stores information indicating the creation date / time and modification date / time of the metadata file, information indicating the size of the metadata slot, information indicating the storage number of the metadata slot, and the like.

The structure of the file entry in the property file includes information such as a file pointer, a metadata pointer, a thumbnail pointer, a file name, a file size, a creation date / time, and an update date / time, as shown in the figure.
The file pointer is information on a pointer that points to the corresponding content file. For example, the location of the corresponding content is specified and indicated by a path managed on the file system side.
The thumbnail pointer indicates a thumbnail slot associated with the current file entry in the thumbnail file (that is, a thumbnail slot corresponding to the content file indicated by the file pointer of the current file entry). The thumbnail file is formed, for example, by logically connecting fixed-length thumbnail slots. Therefore, as the thumbnail pointer, for example, one thumbnail slot can be specified by specifying the arrangement order of the thumbnail slots in the thumbnail file.
The thumbnail image data stored in the thumbnail slot in the thumbnail file can be used so as to be displayed as an icon (thumbnail image) indicating the file when displaying the file list image to be displayed on the display unit 7. it can.

  The metadata pointer indicates a metadata slot (that is, a metadata slot corresponding to the content file indicated by the file pointer of the current file entry) associated with the current file entry in the metadata file. Since the metadata file is also formed by logically connecting fixed-length metadata slots, for example, by specifying the arrangement order of the metadata slots in the metadata file, for example, as a metadata pointer, One metadata slot can be specified.

  The file name, file size, creation date / time, and update date / time in the file entry store information on the file name, size, creation date / time, and update date / time of the content file indicated by the file pointer of the current file entry.

  Although not shown here, the file entry can store information other than the file pointer, metadata pointer, thumbnail pointer, file name, file size, creation date / time, and update date / time described above. As an example, when the system using the management file according to the present embodiment is equipped with a positioning system such as GPS (Global Positioning System), the position information measured by this positioning system is also a file. It is stored in the information element of the entry.

As can be understood from the above description, each content file stored in the medium (HDD 14) of the digital video camera 1 is associated with the file entry by the file pointer in the file entry. Then, one thumbnail slot is specified by referring to the thumbnail pointer of this file entry, and this thumbnail slot corresponds to the content file associated with the file pointer. One metadata slot designated by the metadata pointer of this file entry also corresponds to the content file associated by the file pointer.
That is, depending on the management file, one content file stored in the medium, thumbnail image data (thumbnail slot) associated with the content file, and information (metadata) of arbitrary content related to the content file Slot) is managed in such a manner that the property file pointer is associated with the axis.

  By using such file management information by an application that processes a content file, the management of the content file becomes more efficient than when relying only on the file system, for example. For example, when searching for a file, by adding information stored in a file entry or information stored in a metadata slot as a search condition, the search can be performed by inputting more search conditions than based on the file system. Is possible. That is, a higher search function is provided. Further, it is advantageous in the case where the content file stored in the HDD 14 is displayed on the display unit 7. For example, when displaying a thumbnail image, the thumbnail image can be read out from the thumbnail file and reproduced and output. Therefore, it is not necessary to access the content file data of the HDD 14 and generate a thumbnail image each time, and the list image is displayed accordingly. The screen display becomes faster. In addition, by using information stored in the file entry, information stored in the metadata slot, and the like, various attached information can be presented as a list display.

FIG. 4 shows a system configuration in a hierarchical model when file management by the FAT file system and content file management by the management file are performed as described above.
First, this hierarchical model is roughly divided into a software layer and a hardware layer as a lower layer.
In this case, the software layer corresponds to a program executed by the CPU and software processing realized by various firmware, middleware, and the like in a device that is a host (digital video camera 1 in the embodiment) with respect to the medium. It is supposed to be. The software layer in this case is basically configured such that the management file control system is located after the application file system and the device driver are located from the upper layer to the lower layer as shown in the figure.
It can be considered that the physical storage area of the medium (HDD 14) itself is located in the hardware layer.

  The application in this case has various processing functions (recording, reproduction, update, etc.) for the file, and makes an access request at the file level to the management file control system.

The file system corresponds to software that realizes the function as the file system. In this embodiment, since the FAT file system is adopted, the software that provides the file system function is also configured corresponding to the FAT file system.
As is well known, the FAT file system manages storage files by a tree-type directory structure, and manages files as a cluster unit set. Such file management and data management are realized by management information (file system management information) including directory entries and table information called FAT (File Allocation Table). The directory entry is information indicating the location of a file or directory (subdirectory) on the medium at the cluster level, and the FAT is information indicating a chain (link or link) at the cluster level that forms the directory or file. File system such as access to the file system management information (directory entry, FAT), and update of the file system management information in accordance with the file operation result such as reading (playing) or writing (adding or updating) of the file Operations on the management information itself are performed according to the hierarchy of the file system.
In the file system, an access request at a file level from an application (and a management file control system to be described later) is converted into a cluster level that is a data management unit in the FAT file system format, and is sent to the device driver. Make an access request.

  The device driver corresponds to software for controlling the media as a device to be controlled, and receives an access request from the file system at the cluster level according to the FAT file system format in units of data writing / reading on the media. Convert to a certain sector level and make a request to access the media.

The media in this case is logically formatted (initialized) according to the FAT file system. In FIG. 1, the HDD corresponds to the medium here. In response to the sector level access request from the device driver, the medium reads data from the designated sector address and returns it to the device driver. That is, an access response at the sector level is executed.
The device driver receives an access response from the medium at the sector level, that is, receives data in units of sectors, and treats the received data as data in units of clusters and passes it to the file system (access response at the cluster level). ).
In the file system, data received from the device driver is transferred to the application as file level data. The application executes a required process at the application level according to, for example, an operation input by the user on the data received as a file.

The management file control system is compatible with software that realizes a file operation function such as generation of a management file, reading to a medium, and writing shown in FIG. For example, when an application searches for a content file using a management file, the management file control system refers to the management file that is read from the medium and imported.
In addition, when performing file operations such as recording, deleting, and updating a content file as application file operations, access requests and read data are received via the management file control system. In this case, the application and the management file control system may perform communication at the file level using, for example, a file name or a file ID determined mutually.
In addition, the management file control system updates (rewrites) the management file so that the operation result is reflected in accordance with the file operation result by the application as described above. In this way, the management file control system operates the management file. In the present embodiment, as described with reference to FIG. 2, there is also a backup file of the management file, and this backup file also needs to be updated according to the operation result of the content file by the application. Such a file operation of the backup file is also executed by the management file control system.
For example, when the management file control system makes a management file access request, it makes a request to the file system at the file level in the same manner as the application. In the lower layer than the file system, an access request and data are exchanged in the same manner as described above, and the data of the management file is returned to the management file control system.

  As described above as a problem in the prior art, a file stored in a storage medium is managed by a file system (FAT: basic file management means) as described above. If a specific file type is managed by a management file, the file management contents on the file system side and the file management contents by the management file must be consistent with each other. become.

The inconsistency of the file management contents as described above is caused by the rewriting process of the file system and the management file due to a failure such as the power being cut off while the file system and the management file are being rewritten according to the operation of the content file. Occurs when it is forcibly interrupted. As a specific example, if the management file is rewritten after successfully updating the file system, and the processing is interrupted at this time, the contents of this management file are stored and retained as they were before the update. Or the file itself has been destroyed, and the file system that has been successfully updated cannot be matched.
However, normally, when the power is turned on, it is impossible to know in what state the previous power stop was performed. That is, when the power is turned on, it is impossible to know whether or not the file system and the management file are consistent. In this case, in order to check the consistency of the file management contents between the file system side and the management file, for example, the content file stored in the storage medium is accessed by the file system, and the file management contents of the management file are It will be compared with the match / mismatch. Such processing requires frequent time because frequent access to a storage medium such as an HDD and comparison processing are repeated. Also, the processing time increases as the number of content files increases. Such processing is generally performed as one of startup processing at the time of power-on, which causes disadvantages such as longer startup time.

  Therefore, as a technical configuration for solving the above inconvenience, status information describing the file management contents on the file system side and the state (file management contents state) regarding the file management contents of the management file is stored in a nonvolatile storage. The area (in this embodiment, the HDD 14 or the non-volatile memory 12a) is stored and held. For example, at startup, the status information is referred to determine the consistency between the file system and the management file. It is possible to do so. The status information is changed at any time according to the status that changes according to the progress of the file system management information and management file rewrite process, for example, depending on the operation of the content file. I will let you.

  Referring to FIG. 5, a correspondence example between the flow of management content change (update) and management file rewrite processing (file management content update processing) in response to a file operation and the status information content explain. Here, in order to clarify the difference between the file system and the management file rewriting process as the present embodiment to be described later, it is assumed that there is no management file backup file present in the present embodiment. The processing procedure is as follows.

FIG. 5A shows a procedure example of file management content update processing corresponding to, for example, a content file operation, and FIG. 5B shows a file system corresponding to the procedure shown in FIG. The file management content and the state of the management file regarding the file management content (file management content status) are shown.
First, in this case, the state as procedure 1 in FIG. 5A is that the content files managed as being stored in the storage medium by the file system are two content files A and B, and The management file is also in a state where the content files A and B are properly managed. Further, when this state is seen in the flow of processing related to the content file operation, it is assumed that the content file operation is not being performed, and that the processing state is “steady”.
At this time, as described above, both manage the content files A and B appropriately. In other words, as shown in FIG. 5B, the file management content state at this time is “consistent” with the actual recording state (recording state at a level below the file system). I can say that.

Then, it is assumed that the content file C is added as a file operation under the state as the procedure 1 in FIG. In response to this file operation, first, the process for the actual content file C is performed according to the procedure 2 following the procedure 1 (processing status: “adding content file”). That is, the data as the content file C is actually written to the HDD 14 and the rewriting of the file system management information is executed so that the writing result of the data of the content file C is reflected.
At this time, for example, the content file C can be regarded as being created at a level below the file system, whereas the management file does not reflect any information about the content file C. is there. For this reason, the recording state of the actual content file at this time and the management file are not matched. That is, in the case of the procedure 2, the file management content state shown in FIG. 5B is “inconsistent”.

  The next procedure 3 in FIG. 5A is an interval period from the completion of the additional recording of the content file C according to the procedure 2 to the start of rewriting the next management file. At this time, since it is not the timing at which the CPU actually executes the process for data rewriting, the processing state is “steady”. However, when comparing the file management contents of the file system and the management file, the content file C is properly managed in addition to the content files A and B depending on the file system management information. In the management file, only the content files A and B are still managed. Therefore, the file management content state shown in FIG. 5B is “inconsistent”.

  The subsequent procedure 4 in FIG. 5A is a process of rewriting the management file so that the content file C is properly managed by the management file. In other words, the processing status at this time is “management file update in progress”. The contents of the management file at this time are in an incomplete state during rewriting. That is, the contents of the management file are not normal. Therefore, the file management content state shown in FIG. 5B is treated as “management file error”.

  Then, when the rewriting of the file system management information in the above procedure 4 is completed and the “steady” processing status shown in the procedure 5 is reached, both the file system and the management file store the content files A, B, and C. It has contents to be properly managed. That is, the file management content state in FIG. 5B returns to “consistent”.

As the status information, the content is rewritten (changed) as shown in FIG. 5B in accordance with the transition of the processing status in accordance with steps 1 to 5 shown in FIG. To. For example, every time the power is turned on to start up, the contents of the status information stored and held at that time are referred to.
For example, in the “steady state” processing status of procedure 1, the processing is terminated due to a failure such as the power being cut off, or in the case of procedure 1, the power is normally turned off in this state. If the status information has been performed, the status information ends with the content indicating “match” being stored and held. Then, when the status information is referred to at the next power-on time, the content indicating this “match” is recognized.
If the status information indicates “consistency”, the startup process is normally completed without executing a process for restoring consistency between the file system and the management file. In this case, although the content file C added last at the time of the previous power-on does not exist, the use of the device can be started from a state in which the files A and B are normally managed.

On the other hand, if a failure such as an unexpected power interruption occurs in the middle of the processing status of “content file adding” or “steady” in step 2 or step 3, "Is stored, and the content indicating this" inconsistency "is referred to at the next startup. When it is recognized in this way that it is “inconsistent”, the file system management information is compared with the contents of the management file to obtain a difference between the contents. Then, the file system management information or the contents of the management file are rewritten so that this difference is eliminated.
In addition, when a failure occurs during the processing status of “Updating management file” in step 4 and the process is terminated halfway, status information indicating “abnormal management file” is stored, and this “ The contents indicating “abnormal management file” are referred to.
In this case, two cases can be considered as the state of the management file. One is a state in which the management file properly manages only the content files A and B and not the content file C, and the other is a case where the management file itself is destroyed. The former occurs when the interruption ends when the management file update processing of the storage medium (HDD 14) is not yet executed, for example, when the contents of the management file are being rewritten on the memory. The latter occurs, for example, when rewriting of the management file in the memory is finished and the interruption is finished while the contents are being written to the storage medium.
In the former case, by comparing the contents of the file system and the management file, it is recognized as a difference that the content file C is not managed on the management file side. Accordingly, in this case as well, the content file C is deleted and the file system management information is rewritten so that only the content files A and B are properly managed in the same manner as in the previous procedure 3. be able to. Alternatively, the management file can be rewritten so that the content file C is properly managed by the management file.
When the management file itself is destroyed as in the latter case, the management file is recreated. For this purpose, a file system is used to access all the content files stored in the storage medium, collect information necessary for creating the management file, and create a management file using these information. Then, the created management file is stored again in the storage medium. In this way, the destroyed management file returns to normal. At this time, the backup file is also updated so as to have the same content as the re-created management file.

  In addition, since the status information is “consistent” at the next power-up when the processing is completed under the “steady” status in step 5, the consistency between the file system and the management file is restored. The startup process is normally completed without executing the process for the above. In this case, the content files A, B, and C are appropriately managed, and the process proceeds to the operation after activation.

As described above, if the status information is used as described with reference to FIG. 5, it is possible to determine whether or not the contents of the file system and the management file are consistent only by referring to the status information first. Become. As a result, for example, it is not necessary to access the content file stored in the storage medium in order to determine consistency at the time of activation, and the activation time is shortened.
Further, since the status information described in FIG. 5 is divided into two states, “inconsistency” and “management file error”, as states other than the consistency, the consistency is determined according to this state classification. An appropriate process for returning can be selected, and the process of restoring consistency is also efficient.

  However, as described above, when the management file is broken due to “management file error”, the management file is recreated from the beginning. In the re-creation process, it is necessary to access all the content files to be managed stored in the storage medium and collect necessary information. In other words, in the case of starting in a state where the management file has been destroyed, the starting time becomes long.

  Therefore, the present embodiment proposes a configuration in which the startup time is further shortened with respect to the startup in a state where the management file is destroyed based on the configuration of FIG. The configuration as this embodiment will be described hereinafter.

In this embodiment, as clearly shown in FIG. 2 and the like, a backup file of the management file is stored in the HDD 14 as a storage medium together with the management file.
In general, a backup file is prepared to restore the contents when the original file of the backup source is destroyed or lost for some reason. For this reason, the backup file is stored in a storage medium, for example. Should have the same content as the original file. In this respect, the same applies to the backup file of the present embodiment. That is, the backup file of the present embodiment should be updated so that it always has the same content as the original management file stored in the HDD 14. When the management file is destroyed or lost, the contents of this backup file are used when the management file is re-created.
Since the backup file can be used in this way, it is not necessary to access all the content files stored in the storage medium as in the case of FIG. 5 in order to re-create the management file from the beginning. In addition, the creation of the management file using the contents of the backup file can be performed, for example, by a process such as copying the data of the contents of the backup file to the data structure of the management file format. Such processing is very short compared to accessing all of the content files stored in the storage medium. In other words, by providing a backup file of the management file, the time required for recovery when the management file is destroyed or lost is shortened, and for example, the start-up time is greatly shortened accordingly.

  As described above, in this embodiment, a backup file for the management file is provided. For this reason, when the file system management information and the management file are updated according to the operation of the content file, it is necessary to update the backup file. In addition, it is necessary to determine the consistency of the management file not only between the data management status at the level below the file system and the management file, but also between the three parties including the backup file. In addition, status information according to FIG. 5 is used for the consistency determination.

FIG. 6 shows the correspondence between the flow of rewriting processing of the file system, the management file, and the backup file and the state to be indicated by the status information according to a certain content file operation example as the present embodiment. .
Also in this case, similarly to FIG. 5, FIG. 6A shows an example of a processing procedure according to the content file operation, and FIG. 6B shows FIG. 6A. The transition about the content state of the management file according to the procedure is shown. The file management content state shown in FIG. 6B should be considered as including a backup file corresponding to this management file.
Further, as an example of the content file operation in this case, it is assumed that the content file C is newly recorded from the state in which the content files A and B are managed as in the case of FIG.

In this case, as the procedure 1 in FIG. 6A, the state in which the processing state is “steady” indicates that the content files managed as being stored in the storage medium by the file system are the content files A and B. The content files A and B are appropriately managed by the management file. Thus, the contents of the content file to be managed first are the same as in FIG. Furthermore, in this case, the backup file of the management file is also assumed to have contents that match the current management file, and the contents files A and B are appropriately managed.
Therefore, at this time, all of the three of the file system, the management file, and the backup file properly manage the content files A and B. That is, the file management content state is in a state of being “consistent” with the file system (and the backup file) as shown in FIG.

Also in this case, as a file operation under the state as the procedure 1 in FIG. 6A, additional recording of the content file C is performed. As step 2 following step 1 corresponding to this file operation, the processing status is “adding content file” as in the case of FIG. 5, and the actual data of content file C is written to HDD 14. In addition, the file system management information (directory entry, FAT) is rewritten to register the content file C.
At this time, as in FIG. 5, for example, the content file C can be regarded as being created at a level below the file system, whereas the management file contains information on the content file C. The state is not reflected at all. Therefore, also in the case of procedure 2 in this case, the file management content state shown in FIG. 6B becomes “inconsistent”.

  The next step 3 in FIG. 6A is “steady state” as an interval period from the completion of rewriting of the file system according to the addition of the content file C in step 2 to the start of rewriting of the next management file. Is the processing status. At this time, depending on the file system management information, in addition to the content files A and B, the content file C is also properly managed, whereas the contents of the management file and the backup file are still content files. Only A and B are managed. Accordingly, the file management content state shown in FIG. 6B changes to “inconsistent”.

  The subsequent procedure 4 in FIG. 6A is a process of rewriting the management file so that the content file C is properly managed by the management file, and the processing status is “Updating management file”. At this time as well, as in step 4 of FIG. 5, the contents of the management file are in an indeterminate state during rewriting. Therefore, the state of the management file shown in FIG. File abnormal ".

The procedure 5 is a stage at which the rewrite of the file system management information in the procedure 4 is completed and a “steady” processing state is reached. In the case of FIG. 5, at this stage, both the file system and the management file have contents for properly managing the content files A, B, and C, and the contents status of the file system and the management file is “consistent”. "
However, in the case of FIG. 6, the file system and the management file have the contents for properly managing the content files A, B, and C as described above, but only the contents A and B are managed for the backup file. The previous contents remain unchanged. For this reason, as the state of the management file, the backup file corresponding to this management file is inconsistent with the management file. This state is handled as “backup abnormality”.

  Therefore, in the next procedure 6, the process shifts to a “backup update in progress” processing state in which the backup file is rewritten so that the content file C is properly managed by the backup file. In this way, when the contents of the backup file are actually rewritten, the contents are indefinite, and the contents file C has not yet been properly managed. For this reason, the status of the management file (and the backup file) becomes “backup abnormality” following the procedure 5.

  Then, when the rewriting of the file system management information in the above procedure 6 is completed and the “steady” processing status as the procedure 7 is reached, the three of the file system, the management file, and the backup file are transferred to the content file A , B, and C are appropriately managed, and the state of FIG. 6B returns to “match”.

  As the status information of the present embodiment, as shown in FIG. 6B, the contents may be changed in accordance with the transition of the processing status in FIG. Also in the case of the present embodiment, this status information is stored and held in a non-volatile storage area (HDD 14, non-volatile memory 12a, etc.). Refer to the contents of the status information stored in the memory.

  For example, even in this case, if the processing is terminated in the “steady” processing status of the procedure 1 due to the power-off operation or the power being shut off, the status information includes contents indicating “match” Is stored and held, and at the next power-on, the contents indicating this “match” are recognized as the status information. Therefore, in this case, the startup process is normally completed without executing the process for restoring the consistency between the file system, the management file, and the backup file. In this case, the content file C added last at the time of the previous power-on does not exist, but the use of the device can be started from the state where the files A and B are normally managed.

In addition, in the middle of the processing status of “content file adding” and “steady” in the procedure 2 or 3, if the interruption is terminated due to the occurrence of some trouble, status information indicating “inconsistency” is stored. Thus, at the next start-up, the content indicating this “inconsistency” is referred to. When it is recognized that it is “inconsistent” as described above, the contents of the file system management information, the management file, and the backup file are compared with each other as in FIG. In order to solve the problem, the contents of the required file system management information, management file, and backup file are rewritten.
In the inconsistent state of the procedure 2 or procedure 3, the management file and the backup file properly manage only the content files A and B, and the content file C does not exist, whereas the file system management information On the side, in addition to the content files A and B, the content managing the content file C is in an incomplete or complete state.
Therefore, the contents of the file system management information, the management file, the backup file, etc. are changed according to the inconsistency state of the procedure 2 or procedure 3, but the content file C is additionally recorded uniformly. It is conceivable that the content files A and B before the operation are properly returned to the state where they are properly managed. That is, the file management information of the file system is rewritten so as to match the contents of the management file and the backup file.
However, in the file management information of the file system, the contents for managing the content file C are held in a complete state, and the last file operation on the application side additionally records the content file C. If it is known, the contents of the file system management information, the management file, the backup file, etc. may be changed so that the content file C can be matched in a properly managed state. For this purpose, the file system is used to access the content file C stored in the HDD 14, collect information necessary for creating a management file for the content file C, and use the collected information. Then, rewriting for updating the management file is performed so that the content file C is properly managed. Further, the backup file is also updated so that the contents of the updated management file are reflected.

In addition, when the process is terminated in the middle of the processing status of “Updating management file” in step 4, status information indicating “abnormal management file” is stored. The contents shown are referred to.
Also in this case, as in the procedure 4 of FIG. 5, the management file appropriately manages the content files A and B as the management file, but there is no content for managing the content file C, or Because of the imperfection, two possibilities should be considered: the case where the content file C is not managed, and the case where the management file itself is destroyed. In the former case, as in the case of FIG. 5, the management file is rewritten so that the content file C is properly managed by the management file. In addition, when the management file itself is destroyed as in the latter case, the management file is recreated.

  In the case of the present embodiment, when the management file is re-created as described above, for example, the backup file is read and the content is copied to the management file format. . By using the backup file for re-creating the management file in this way, it is not necessary to access all the content files stored in the storage medium using the file system as shown in FIG. The time required to re-create the management file is greatly shortened, and accordingly, the startup time is also shortened.

In addition, if the processing is terminated in the middle of the processing status of “steady” or “updating backup” in the procedure 5 or 6 in FIG. Thus, at the next startup, it is recognized that a “backup abnormality” has occurred.
In this “backup abnormal” state, the file system management information and the management file are in a state where the content files A, B, and C are properly managed and matched, but only the backup file properly manages the content file C. This means that the content has not been saved, or the backup file has been destroyed. Therefore, in this case, the backup file is rewritten or recreated so that the backup file has the same contents as the management file. For this purpose, a necessary data portion may be copied from the data contents of the management file, and the backup file may be rewritten or recreated. In this way, even when the backup file is re-created, it is not necessary to access all the content files stored in the storage medium using the file system, for example.

  In addition, since the status information is “consistent” at the next power-up when the process is completed under the “steady” condition in step 7, especially the file system, management file, and backup file The startup process is normally completed without executing the process for restoring the consistency between the two. In this case, the content files A, B, and C are appropriately managed, and the process proceeds to the operation after activation.

  The status information changed as shown in FIG. 6B is stored and held in the nonvolatile storage area, for example, as data in the system area or as a file of some form that can be managed by the file system. That's fine. In the digital video camera 1 according to the present embodiment, for example, it may be held in the HDD 14 or the nonvolatile memory 12a.

Further, as the most basic form of the status information of the present embodiment, for example, one unit information indicating the state transition shown in FIG. 6B is prepared as status information and stored in a nonvolatile storage area. It may be held.
However, in actually executing the processing shown in FIG. 6A, the software hierarchy for controlling the processing in the flow of FIG. 6A is not the same as described later. For example, in the correspondence with the hierarchical structure in FIG. 2, the application performs control (additional control for the file system) for additional recording processing of the content file corresponding to procedure 2 in FIG. On the other hand, the management file control system controls processes such as management file update and backup file update corresponding to procedures 4 and 6.

Considering such a situation, it can be said that it is not efficient to manage the status information according to the processing flow shown in FIG. 6A by the same software layer.
For example, if the application tries to manage the status information in an integrated manner, the content addition of the procedure 2 can grasp the execution timing almost accurately by itself, so that the contents of the status information can be appropriately changed. In order to recognize the execution timing of subsequent processing, it is necessary to receive a notification from the management file control system. For this reason, for example, due to a communication time lag for notification, there is a disadvantage that an error between the change timing of the status information on the application side and the actual processing timing becomes large.

Therefore, as an actual example of the present embodiment, transition of status information corresponding to the progress of processing shown in FIG. 6B is managed using two status information elements. This point will be described with reference to FIG.
FIGS. 7A and 7B show the same processing procedure example as in FIG. 6A and the same file management content state transition as in FIG. 6B. FIG. 7C shows the content transition of the upper processing layer side status information, which is one status information element, and FIG. 7D shows the lower processing layer, which is the other status information element. The content transition of the side status information is shown.
The upper processing layer side status information is a status information element managed and operated by the application. In the case of the digital video camera 1 of the present embodiment, the status information element is stored and held in the nonvolatile memory 12a under the control of the application. .
The lower processing layer side status information is a status information element managed and operated by the management file control system, which is handled as a lower level for the application, and is stored and held in the HDD 14.

First, in the “steady” status stage of the procedure 1 in FIG. 7A, both the upper processing layer side status information and the lower processing layer side status information indicate “matching”. Then, if the processing status of “adding content” according to the procedure 2 is reached and it is determined that it is time to update the file system by controlling the application, the application sets the status information on the upper processing layer side to “inconsistent”. Change to Also, when the procedure 2 is completed and the status of “steady” as the procedure 3 is entered, the upper processing layer side status information indicates the content of “inconsistency”.
Although it is the status information on the lower processing layer side, since the management file (or backup file) is not yet operated at the stage where the application updates the file system in step 2, the management file control system The status information on the lower processing layer side is not operated. For this reason, the status information on the lower processing layer side is in a state where “match” is indicated from procedure 2 to procedure 3 following procedure 1.

Then, if it is determined that the management file control system should perform control for updating the management file after the transition to step 4, the management file control system stores the status information on the lower processing layer side so far. The content indicating “consistency” is changed to the content indicating “abnormal management file”.
Then, if the update of the management file in the above procedure 4 is completed and it is assumed that the state has changed to the “steady” status as the procedure 5, the management file control system changes the contents of the status information on the lower processing layer side to “ Change to "Backup Abnormal". In addition, even when the backup file is updated by the procedure 6 following this, the management file control system maintains the content of “backup abnormality” from the start of the procedure 5.

  As described above, while the management file control system is updating the management file and the backup file according to steps 4 to 6, in the application, the upper processing layer side status information is particularly Do not make any changes. For this reason, the upper processing layer side status information in the period corresponding to the procedure 4 to the procedure 6 maintains the content of “inconsistency” set according to the start timing of the procedure 2.

  Then, when the update of the backup file as the procedure 6 is finished and the state is changed to the “steady state” as the procedure 7, the management file control system changes the contents of the status information on the lower processing layer side. Change from "backup abnormal" to "consistent". The application is also configured to return the upper processing layer side status information from “inconsistent” to “consistent”.

For example, when determining the consistency of the management file at the time of power activation, the contents of the status information elements shown in broken lines throughout FIGS. 7C and 7D are handled as the contents indicated by the status information. Is done. In other words, at the next power-up when the processing is terminated halfway in the state between procedure 1 and procedure 3, the content of the status information on the upper processing layer side is adopted as the content of the status information. Perform sex determination. In addition, at the time of the next power-up when the processing is terminated halfway in the state between procedure 4 and procedure 7, the contents of the status information on the lower processing layer side are adopted and matched as the contents of the status information. Make sex determination. For confirmation, in the status information on the lower processing layer side, the contents of “match” set corresponding to the procedures 2 and 3 are invalid.
Thus, if the contents of the status information to be adopted corresponding to each procedure are selected from the upper processing layer side status information and the lower processing layer side status information, the original status information shown in FIG. It will match the content transition.

FIG. 8 shows the processing procedure shown in FIG. 7A and processing for changing the status information (upper processing layer side status information and lower processing layer side status information) shown in FIGS. 7C and 7D. Is shown as processing between hierarchies of the application, the management file control system, and the file system.
In the example of FIG. 7, the content file C is additionally recorded. In response to this, first, the application requests the management file control system to record the content file in accordance with the procedure of step S101. The start of the process in step S101 corresponds to the transition from the state of procedure 1 in FIG.

  In addition, the application requests the management file control system to record a content file (becomes content file C in FIG. 7) in step S101, and, as shown in step S102, operation content information indicating the file operation content. Executes a process of rewriting so as to mean that the content file is recorded. The operation content information is managed by the application, as can be understood from the procedure in step S102, and should be stored and held in, for example, the nonvolatile memory 12a. Step S103 is a procedure in which a response is returned from the lower processing layer in response to the operation content information being updated and written in the nonvolatile memory 12a, and this is received by the application.

The operation content information can be used as follows, for example, in correspondence with FIG. Here, assuming that the processing is terminated in the situation of the procedure 3 in FIG. 7, the status information indicates “inconsistency” at the next activation, and the file system is a content file as the inconsistency state. While A, B, and C are managed, the management file and the backup file are only the content files A and B, and the content file C is not managed.
This state is the same as the state in the case where the processing is terminated halfway in the processing state of step 5 in FIG. Since the processing of FIG. 7 is in response to a file operation for recording the content file C, it is preferable to restore consistency in a state where the content file C is properly managed if possible. On the other hand, as will be described later, the processing of FIG. 9 is in response to a file operation for deleting the content file C. Therefore, if possible, the content file C is deleted and only the content files A and B are appropriate. It is preferable to restore consistency in a managed state.
For example, if the operation content information does not exist, it is due to the interruption when the content file C is additionally recorded in the above-described inconsistent state, or the content file C is deleted. It is difficult to determine whether it is due to interruptions when you are. Therefore, if the operation content information is provided and stored in the non-volatile memory 12a as in the present embodiment, the operation content information is read and referred to at the time of power-on, before the start-up. It is possible to recognize what the last file operation is, for example, when restoring the consistency between the file system management information and the management file (and backup file), so that the file management content is more appropriate Is possible.

  Further, the operation content information is used when branching the process depending on whether the last content file operation is an additional recording or a deletion in executing the activation process as will be described later with reference to FIG. It is also used as information for determining what the last content file operation was.

  In addition, when the application rewrites the operation content information in steps S102 and S103 (response), the content of the upper processing layer side status information is made “consistent” until then in steps S104 and S105 (response). The process is changed to “inconsistency” from the state where it has been stored, and is stored again in the nonvolatile memory 12a.

  In addition, in the management file control system that has received the content file recording request in step S101, a request for creating a content file is made to the file system in step S106. When the file system makes a response in response to this request in step S107, the management file control system that has received this response returns a response to the application in step S108.

  In step S109, the application that has received the response in step S108 requests the management file control system to register content in the management file in accordance with the recording of the current content file. Here, as a process in response to this request, the management file control system first shows "management file abnormality" from the "matching" so far in the lower processing layer side status information in step S110. The control to change to is executed. When the change of the lower processing layer side status information is completed by the control in step S110, a response from the lower processing layer is returned, so the management file control system receives this response in step S111. Here, the lower processing layer side status information stored in the HDD 14 is not a file format that can be managed by the file system, but is information stored in the system area. For this reason, in FIG. The change / rewrite processing of the status information on the lower processing layer side is shown without going through the file system.

  Next, in step S112, the management file control system performs processing for updating (rewriting) the management file in accordance with the recording of the current content file. In other words, for example, the management file control system changes the management file read from the HDD 14 via the file system according to the current content file recording, and the changed contents are reflected in the contents of the management file stored in the HDD 14. As described above, access to the HDD 14 and data recording are performed via the file system. When the update of the management file stored in the HDD 14 is completed, a response is returned from the lower layer of the management file control system. When the management file control system receives this response at step S113, it further returns a response to the application at step S114.

  By receiving the response returned from the management file control system in step S114, the application recognizes that the registration of the content file in the management file requested in step S109 has been completed normally. Then, in step S115, the application makes a request for updating the backup file to the management file control system.

  Upon receiving the backup file update request, the management file control system changes the content of the lower processing layer side status information from the previous “management file error” to “backup error” in step S116 prior to the backup file update process. Then, the process for re-storing is executed. When the storage of the backup file is completed, a response returned from the lower processing layer is received in step S117.

  When the update of the lower processing layer side status information is completed, the management file control system executes a process for updating the backup file using the file system in step S118. That is, for example, the backup file is updated so that the contents of the management file updated in step S112 are reflected along with the reading and writing of the backup file to the HDD 14 using the file system. The response of this process is returned as the procedure of step S119.

  When the update of the backup file is completed as described above, the management file control system further displays “consistency” in the status information on the lower processing layer side that has previously indicated “backup abnormality” in step S120. Make a change. A response to this process is returned as step S121.

The management file control system that has received the response in step S121 returns a response to the application in step S122. By receiving this response, the application recognizes that the update of the backup file requested in step S115 has been executed normally.
Then, as shown in step S123, the application executes processing for changing the upper processing layer side status information from “unmatched” to “consistent”. A response from the lower processing layer corresponding to this processing is returned in step S124.
Subsequently, as shown in step S125, the application executes a process for clearing the operation content information that has shown the recording of the content file so far. A response to this process is made in step S126.

For example, in FIG. 7, according to the transition from the procedure 7 to the procedure 8, both the upper processing layer side status information and the lower processing layer side status information are returned to the contents indicating “match”. As will be understood from FIG. 8, the status information on the lower processing layer side returns to the matching timing after the application receives a response in step S122. On the other hand, the status information on the lower processing layer side returns from “abnormal backup” to “consistent” almost immediately after the update of the backup file is completed in steps S118 and S119. That is, as the status information corresponding to the procedure 7 of FIG. 7 and indicating the content of “match”, the status information on the lower processing layer side is changed at a timing closer to the actual processing than the status information on the upper processing layer side. I understand that
The timing at which the status information on the lower processing layer side is changed from “consistent” to “management file error” (the processing timing in step S110) is a content registration (management file update) request to the management file in step S109. As a response, it is executed together with the management file update process of S112. Similarly, the timing at which the lower processing layer side status information is changed from “management file error” to “backup error” (the processing timing in step S116) is also in response to the backup file update request in step S115. This is executed together with the backup file update process. In other words, the timing when the status information on the lower processing layer side has the contents of “management file error” or “backup error” is the timing when the management file is actually rewritten or when the backup file is actually rewritten It can be considered that it is almost consistent with.
If the management file control system updates the backup file or if the management file control system tries to manage these statuses such as "management file error" and "backup error" with the status information on the upper processing layer side The status information content is changed after receiving this response. In other words, the timing indicating “management file error” and “backup error” as the status information will deviate correspondingly to the actual processing status timing, and the reliability as status information will be impaired. Become.

  By the way, the content file operation procedure of FIG. 7 illustrates the additional recording of the content file, but the file operation for deleting the content file can also be performed according to the procedure of FIG. As a specific example, it is assumed that the content files A, B, and C are properly managed in the state of “normal” in the procedure 1, and the content file C is deleted from this state. In this case, in the procedure 2, first, processing is performed so that the content file C is deleted on the file system (during content deletion). Next, as the procedure 4 for shifting from the “steady” state of the procedure 3, the content of the management file is changed so that the content file C is deleted and only the content files A and B are appropriately managed. become. Then, in the procedure 6 for shifting from the “steady” state of the procedure 5, the backup file is updated so as to have the same contents as the management file changed in the procedure 4. In such a processing procedure, the file system management information, the management file, and the backup file are matched in a state where the content file C is deleted and only the content files A and B are managed in the “steady” situation of the procedure 7. Is obtained.

However, when the content file is deleted by the procedure according to FIG. 7, the following inconvenience may occur.
Assuming that the content file is being deleted according to the procedure according to FIG. 7, it is assumed that the processing is interrupted due to power interruption or the like while the content deleting process on the file system side in step 2 is being executed. . As an inconsistent state at this time, as the file system management information, the information for managing the content file C does not remain in a complete state, but one of the management files has not been rewritten at this stage. Thus, the contents for managing the content file C remain in a normal state.

As described above, if inconsistency as described above has occurred, processing for restoring the consistency is executed by rewriting the management file or the file system management information. In the above case, in the file system management information, the information for managing the content file C is the same as that lost, so the content file C is deleted from the management file (and backup file). In this way, matching is achieved.
However, since the file deletion at the file system level is realized by rewriting on the file system management information, the actual data itself of the content file C is highly likely to be recorded in the HDD 14 in a complete state. . From this point of view, even though the last file operation is intended to delete the content file C, it is preferable to restore the content file C so that it can be properly managed after the power is turned on. It can also be taken. Even if the content file C is managed to be restored, if the user wants to delete the content file C, the deletion operation may be performed again.

  Therefore, according to the present embodiment, even when the processing is interrupted during deletion of the content file, the content file that was the deletion target should be restored and managed as much as possible at the next startup. Based on the idea, when deleting a content file, the procedure shown in FIG. 9 is executed. FIG. 9 (a) shows an example of a processing procedure according to content file deletion, FIG. 9 (b) shows a file management content state, and FIGS. 9 (c) and 9 (d) show The transition of the upper processing layer side status information and the lower processing layer side status information is shown, respectively.

First, in the stage of “steady state” in the procedure 1 of FIG. 9A, the content file A, B, C is managed by the file system as being stored in the HDD 14, and the management file and the backup are stored. The content files A, B, and C are appropriately managed depending on the files. Therefore, the file management content state is “consistent” as shown in FIG. 9B. Further, the upper processing layer side status information and the lower processing layer side status information both indicate “match”.
Then, the procedure for deleting the content file C is started from the procedure 2 onward. As the procedure 2, the content file C is first deleted for the management file, and the content file A is deleted. , B so that only the contents are managed. When the management file is being updated, the management file can be regarded as being incomplete due to the rewriting process, so the file management content state is as shown in FIG. 9B. “Management file error” occurs. When the procedure 2 is completed, in the next procedure 3, the processing state becomes “steady” in a state where the management file has contents for managing only the content files A and B. At this time, the management file is in a normal state corresponding to the file operation (deletion of the content file C), whereas the backup file is in a state where the content file C remains without being deleted. . For this reason, as shown in FIG. 9B, the file management content state becomes “backup abnormality” indicating that the corresponding backup file is abnormal.

  Therefore, after the management file is first updated as described above, the backup file is updated so that the contents of the management file in the above procedure 3 are reflected by the following procedure 4. Move to the processing status. At this time, since the backup file is being rewritten and is in an incomplete state, “backup abnormality” is taken over as shown in FIG.

  In the state where the procedure 4 is finished and the procedure 5 is “steady”, the management file and the backup file are consistent. However, depending on the file system, the content file C is properly managed. For this reason, the file management content state shown in FIG. 9B is “inconsistent” because the file system management information is not consistent.

Therefore, according to the following procedure 6, the file system management information is updated so that the content file C is deleted as the file system management information. The processing status as the procedure 6 is “contents being deleted”. Also at this time, since the file system management information is being rewritten and the content file C is not properly deleted, the file management content state shown in FIG. Continue “inconsistency”.
Then, when the rewriting of the file system management information in the above step 6 is completed and the state is changed to the “steady state” in the step 7, the file system management information is also used in the same manner as the management file (and backup file). Therefore, the content file C is deleted, and the content files A and B stored in the HDD 14 have the contents for normal management, so that the “consistent” state is obtained.

Further, according to the flow of the processing procedure described above, the contents of the upper processing layer side status information and the lower processing layer side status information are changed as shown in FIGS.
First, in the state of the procedure 1, both the upper processing layer side status information and the lower processing layer side status information indicate “match”. When the procedure 2 is started, the upper processing layer side status information is changed to “inconsistent”. Further, the status information on the lower processing layer side is changed to “management file error” in response to the management file being updated.

Further, when the management file update processing in the procedure 2 is completed and the state is changed to the “steady” state in the procedure 3, as described above, the state becomes “backup abnormal”. Therefore, the status information on the lower processing layer side is changed from “management file error” to “backup error” according to the timing when the management file update process in step 2 is completed and the state is changed to the state in step 3. Is done.
Further, even when the backup file is updated by the procedure 4, it is in the “backup abnormality” state, and therefore the status information on the lower processing layer side continues the “backup abnormality” from the procedure 3.
When the update of the backup file in step 4 is completed and the state transitions to the “steady” state in step 5, the status information on the lower processing layer side is changed to “inconsistent”, and the content in the next step 6 is further changed. The same “inconsistency” is continued even when rewriting the file system management information for file deletion.
For the upper processing layer side status information, the same “inconsistency” is continued until the processing procedure as the procedure 6 is completed after transitioning to the procedure 2 to be “inconsistency”.

  When the rewriting of the file system management information in step 6 is completed and the state transitions to the “steady” state in step 7, both the upper processing layer side status information and the lower processing layer side status information are changed to “consistent”. .

  For example, in determining consistency at the time of power activation, the content of the status information element shown in broken lines across FIGS. 9C and 9D is handled as the state indicated by the status information. The In other words, at the time of the next power-up when the process is aborted in the state between procedure 1 and procedure 4, the content of the status information on the lower processing layer side is adopted and managed as the content of the status information. Check consistency of information group. In addition, at the time of the next power-up when the processing is terminated halfway in the state between the procedure 5 and the procedure 7, the content of the status information on the lower processing layer side is adopted and matched as the content of the status information. A sex determination is made.

  FIG. 10 shows the processing procedure shown in FIG. 9A and processing for changing the status information (upper processing layer side status information and lower processing layer side status information) shown in FIGS. 9C and 9D. Are shown as processing between the hierarchy of the application, the management file control system, and the file system.

  In the example of FIG. 9, the deletion of the content file C is a file operation, and the procedure 2 is to delete the content file C from the management file. For this purpose, the application first requests the management file control system to delete the registered content of the content file from the management file according to the procedure of step S201.

  Further, the application executes the process of step S201, and also executes a process of rewriting the operation content information so as to mean the deletion of the content file, as shown as step S202. When the update of the operation content information on the non-volatile memory 12a is completed, the response is returned from the lower processing layer, and the application receives it in step S203.

  In addition, when the application rewrites the operation content information in steps S202 and S203 (responses), the content of the upper processing layer side status information has been made “consistent” so far in steps S204 and S205 (responses). The process is changed to “inconsistency” from the state where it has been stored, and is stored again in the nonvolatile memory 12a.

  In the management file control system that has received the content file recording request in step S201, the status information on the lower processing layer side is changed from “consistent” to “management file error” in step S206. To execute the process. When the update of the lower processing layer side status information is completed, a response is returned from the lower processing layer, and the management file control system receives the response in step S207.

  Subsequently, the management file control system performs processing for updating (rewriting) the management file in accordance with the current deletion of the content file. That is, the management file control system changes the management file read from the HDD 14 via the file system in accordance with the current deletion of the content file (for example, registration deletion of the content file C), and the changed content is stored in the HDD 14. In order to be reflected in the contents of the management file, access to the HDD 14 and data recording are performed via the file system. When the update of the management file stored in the HDD 14 is completed, a response is returned from the lower layer of the management file control system. When the management file control system receives this response in step S209, it further returns a response to the application in step S210.

The application that has received the response in step S210 recognizes that the registration deletion of the content file from the management file requested in step S201 has been completed. Subsequently, in step S211, the application requests the management file control system to update the backup file.
Upon receiving the backup file update request, the management file control system changes the contents of the lower processing layer side status information from the previous “management file error” to “backup error” in step S212 prior to the backup file update process. Then, the process for re-storing is executed. When the storage of the backup file is completed, a response returned from the lower processing layer is received in step S213.

  When the update of the lower processing layer side status information is completed, the management file control system executes a process for updating the backup file using the file system in step S214. That is, the backup file is updated so that the contents of the management file updated in step S208 are reflected as read and write operations of the backup file to the HDD 14 using the file system. The response of this process is returned as the procedure of step S215. The management file control system that has received this response returns a response to the application in step S216.

  By receiving the response returned from the management file control system in step S216, the application recognizes that the update of the backup file requested in step S211 has been completed normally. Then, in step S217, the application requests deletion of the content file at the file system level.

  In the management file control system that has received the content file deletion request, first, before the content file deletion processing, in step S218, the content of the status information on the lower processing layer side is changed from the “backup abnormality” so far to “not valid”. Change to show "consistency". A response to this process is returned as step S219.

When the update of the lower processing layer side status information is completed, the management file control system executes the deletion of the content file with control over the file system in step S220. That is, the management file control system rewrites the contents of the file system management information so that the content file to be deleted is actually deleted. A response to this process is returned as step S221.
When the management file control system receives the response in step S221, the management file control system further changes the status information on the lower processing layer side so as to indicate “match” in step S221. A response to this processing is returned to the management file control system as step S223. Upon receiving this response, the management file control system further returns a response to the application in step S224. By receiving this response, the application recognizes that the content file deletion request requested in step S217 has been executed normally.

After that, as shown in step S225, the application executes a process for changing the upper processing layer side status information from “unmatched” to “consistent”. A response from the lower processing layer corresponding to this processing is returned in step S226.
Subsequently, as shown in step S227, the application executes a process for clearing the operation content information that has been recorded until now. A response to this process is made in step S228.

The flowchart of FIG. 11 shows an example of a processing procedure for restoring consistency between the file system management information, the management file, and the backup file when the digital video camera 1 is activated.
The processing procedure shown in this figure executes the processing procedure described with reference to FIGS. 7 and 8 according to the recording operation of the content file, and executes the processing procedure described with reference to FIGS. 9 and 10 according to the deletion operation. It is assumed that it is. In the processing shown in this figure, for example, a hardware device having a program execution function such as the CPU 10 executes a program as a software layer (application, management file control system, file system, and device driver) shown in FIG. This is realized. Such a program is stored in the ROM 11, the nonvolatile memory 12a, the HDD 14, or the like, for example. Alternatively, the program can be stored in, for example, a removable storage medium, and can be stored in the digital still camera 1 so as to be installed later using this storage medium. It is also conceivable that the data is stored in a storage device in a server on the network, acquired by downloading via the network, and installed in the digital still camera 1.

In FIG. 11, when the power supply is finally stopped in step S301 (the stop of the power supply here includes both the normal power-off and the stop due to the failure of the power supply being cut off). ) Is determined.
For this purpose, the operation content information shown in FIGS. 8 and 10 is used. That is, the non-volatile memory 12a is accessed to refer to the operation content information, and the content file indicates the operation content of the content file. As understood from the description of FIGS. 8 and 10, the operation content information stored and held in the nonvolatile memory 12a is what is being executed as a content file operation when the power supply is stopped for the last time. It was shown. Here, for the sake of simplicity of explanation, the operation content information includes “recording of content file”, “deletion of content file”, and recording / deletion of content file. It is assumed that any one of the three file operation contents is indicated.

  First, if it is determined in step 301 that the content file operation is “normal”, the processing shown in FIG. That is, the normal startup process is executed without executing the processing procedure for returning the consistency.

  On the other hand, if it is determined in step S301 that the content file operation is “record content file”, the process proceeds to step S302 and subsequent steps. If it is determined that the content file operation is “content file recording”, it is estimated that the last power stop is a faulty power interruption during the content file recording process.

In step S302, the contents are discriminated by referring to the status information.
In the present embodiment, the unit as one status information is the upper processing layer side status information and the lower processing as shown in FIGS. 7 (c) (d) and 9 (c) (d). It is formed by combining the layer side status information. As the processing in step S302, first, the upper processing layer side status information stored and held in the nonvolatile memory 12a is referred to. Regarding the recording operation of the content file, as can be seen from FIGS. 7C and 7D, as long as the upper processing layer side status information indicates “consistent”, the file system management information, the management file, And the backup file are stored in the HDD 14 in a state of being consistent with each other. Therefore, in this case, the process shown in FIG.

On the other hand, if it is determined that the upper processing layer side status information indicates “inconsistency”, the lower processing layer side status information stored in the HDD 14 is further accessed as the processing of step S302, and the It is made to refer to the contents. The lower processing layer side status information has three types of contents “match”, “management file abnormality”, and “backup abnormality” as shown in FIGS. 7 and 8 corresponding to the content file recording operation.
Then, the content indicated by the upper processing layer side status information is compared with the content indicated by the lower processing layer side status information. Then, as can be seen from the relationship of FIGS. 7C and 7D, in the state where the upper processing layer side status information indicates “inconsistent” and the lower processing layer side status information indicates “consistent”, the procedure 2 , 3 in the middle of the processing, it is in a state of “inconsistency” which is the content of the upper processing layer side status information. Therefore, when it is recognized that the contents of the upper processing layer side status information and the lower processing layer side status information are in the above state as the processing of step S302, the content of the status information is “inconsistent”. Then, the process proceeds to step S303.

In step S303, the content file that causes the inconsistency is searched. The meaning of this search is to confirm the presence / absence of a content file that is a cause of inconsistency and to identify the content file if such a content file exists. Then, in the next step S304, the presence / absence of a content file which is a cause of inconsistency is determined based on the search result in step S303.
In the processing in steps S303 and S304, the file system management information is compared with the contents of the management file, and the difference is obtained. Two cases can be considered when the processing is terminated halfway during the execution of the procedures 2 and 3 in FIG.
One is a case where the update of the file system management information has been completed. In this case, depending on the file system management information, the last recorded content file is normally managed, but is not managed by the management file. Therefore, by comparing the file system management information and the contents of the management file, it is recognized that the content file recorded last is not managed by the management file. Therefore, in step S304, it is recognized that there is a content file that is a cause of inconsistency and this content file is the last recorded content file, and a positive determination result is obtained in step S304. It is done.
The other is a case where the update of the file system management information has not ended. In this case, the last recorded content file is not managed by either the file system management information or the management file. At this time, although the last recorded content file does not exist, the file system management information and the contents of the management file are consistent. Therefore, in this case, a negative determination result is obtained as step S304.

First, when an affirmative determination result is obtained in step S304, the processes of steps S305 and S306 are executed as a process for resolving the inconsistency and restoring the consistency.
In step S305, the content file identified as the cause of inconsistency, that is, the content file managed by the file system as the last recorded one is registered in the management file. In the next step S306, the backup file is also updated so that the contents of the management file whose contents are updated by the process of step S305 are reflected. When these processes are completed, it is possible to obtain a state in which consistency is restored while the last recorded content file is normally managed.
If a negative determination result is obtained in step S304, the processing shown in the figure is exited as it is. In this case, as the management contents by the file system and management file (and backup file), the last recorded content file does not exist, but it is started in a state where both are consistent. Will be.

If it is determined by the above-described processing in step S302 that the status information on the lower processing layer side is “management file abnormality”, the processing proceeds to step S307 and subsequent steps.
When the status information on the lower processing layer side indicates “management file error”, the contents of the management file are destroyed because the management file itself was interrupted during the rewriting according to procedure 4 in FIG. It means that it is in an illegal state. However, the backup file is stored in a complete state with the content before the last recorded content file is reflected. Therefore, in this case, in step S307, the contents of the backup file are copied and the management file is recreated.
At the stage where the management file is recreated as described above, the last recorded content file is not managed depending on the management file (and backup file), but the file system management information is recorded last. The content file has been managed, and inconsistency has occurred. Therefore, in step S308, the last recorded content file which is a cause of inconsistency at this time is registered in the management file. In subsequent step S309, the backup file is also updated so that the contents of the management file updated in step S308 are reflected. As a result, the consistency is restored while the last recorded content file is normally managed.

If it is recognized in step S302 that the status information on the lower processing layer side is “backup abnormality”, the process of step S310 is executed.
When the status information on the lower processing layer side referred to in this way indicates “backup abnormal”, the processing is interrupted during the rewriting of the backup file according to the procedure 6 in FIG. The file is in an illegal state, for example, it is destroyed. On the other hand, the original management file is stored and managed in the HDD 14 in a normal state after the update according to the previous procedure 4 is completed. In step S310, the backup file is recreated by copying the contents of the management file. Accordingly, in this case as well, the consistency can be restored with the content file recorded last being normally managed.

  If it is determined in step S301 that the content file operation content is “deletion of content file”, the process proceeds to step S311 and subsequent steps. When it is determined that the content file operation content is “content file deletion”, it is estimated that the last power stop is a faulty power shutdown during the content file deletion process.

In step S311, the contents are discriminated by referring to the status information in accordance with the previous step S302.
Also in this case, first, it is determined whether or not the content indicates “match” by referring to the upper processing layer side status information. If “match” is indicated, as can be seen from FIG. 9, the file management content by the file system, the file management content by the management file, and the backup file are stored in the HDD 14 in a state in which they match each other. In this case, the process shown in this figure is directly exited.

On the other hand, if it is determined that the upper processing layer side status information indicates “inconsistency”, the lower processing layer side status information further stored in the HDD 14 is used as the processing of step S311 in this case as well. Access and browse the contents. As shown in FIGS. 9 and 10, the status information on the lower processing layer side in accordance with the content file deletion operation includes three types of contents “consistency”, “inconsistency”, “management file error”, and “backup error”. Have. In this case, an invalid “match” is not indicated as in the case of a content file recording operation.
Therefore, in step S311, it is determined whether the contents of “management file error”, “backup error”, or “inconsistency” are indicated for the lower processing layer side status information.

If it is first determined in step S311 that the management file is abnormal, the process of step S312 is executed.
If the status information on the lower processing layer side indicates “management file error”, the process is interrupted during rewriting of the management file according to procedure 2 in FIG. Is in a state. On the other hand, the backup file is stored and managed in, for example, the HDD 14 in a normal state in which the content file that was the object of the last deletion process remains. Further, the file system management information is also in a normal state in which the content file that has been the object of the last deletion process remains. Therefore, in step S312, the management file is recreated by copying the contents of the backup file. As a result, the consistency is restored in a state where the content file that was the last deletion target is properly managed.
In this case, it is difficult to recognize the original contents because the management file is in an invalid state, and the file system management information and the backup file are the last deletion targets. Therefore, it is difficult to identify the last content file to be deleted by obtaining the difference information. However, for example, if the operation content information stores information that can identify the file that was the operation target, for example, at the file system level, the content file that was the last deletion target is finally deleted. Thus, it is possible to restore the alignment in a managed state.

If it is determined in step S311 that the backup is abnormal, the processes in steps S313 and S314 are executed.
If “abnormal backup” is determined, the processing is interrupted in the middle of one of procedures 3 and 4 in FIG. Accordingly, although the backup file is normally stored and managed in the HDD 14, either the last deleted content file is still registered and managed or stored in an illegal state. Become. In any case, the content file that was last to be deleted is not consistent with the management file that has been deleted.
Therefore, in step S313, first, the backup file is updated or recreated by copying part or all of the contents of the management file (difference from the backup file). Then, in the next step S314, the inconsistent content is deleted at the file system level.
As a result, the alignment is restored in a state where the last content file to be deleted is deleted and managed.

  However, as explained as the basis for the deletion procedure of the content file in FIG. 9, when the specification is to leave the content file that was the last deletion target as much as possible, the content file that was the last deletion target was left It is also possible to restore the alignment in the state. For this purpose, first, the management file is first returned to normal contents matched with the backup file by the same processing as in step S313. After that, by comparing the file system management information with this management file, the existence of the content file that was the last deletion target is obtained as a difference, this content file is registered in the management file, and a backup file corresponding to this content file is registered. To be updated.

  If it is determined in step S311 that it is “inconsistent”, the processing after step S315 is executed. The determination result of inconsistency is obtained when the processing is interrupted in the middle of steps 5 and 6 in FIG.

In step S315, the content file that causes the inconsistency is searched. For this purpose, the file system management information is compared with the contents of the management file, for example, in the same manner as in step S303, and the difference is obtained. When the processing is interrupted in steps 5 and 6, there are actually a case where the state becomes inconsistent and a case where the state becomes consistent. That is, for example, when the process is interrupted in step 5, since it is a stage before rewriting the file system management information, the content file that was the last deletion target has already been deleted depending on the management file Although it is in a state, depending on the file system management information, it is in an inconsistent state in which the state is properly managed. In this state, an affirmative determination result is obtained as the determination result of step S316 corresponding to the search result of step S315. Therefore, in this case, the process proceeds to step S317, and the file system management information is updated so that the last content file to be deleted is managed as being actually deleted at the file system level. As a result, it is possible to restore consistency in a state in which the last content file to be deleted has been deleted.
If the file system management information has contents that have been managed normally without deleting the content file that was the last target for deletion, the last file for the management file and backup file By updating the content file that was to be deleted, it is possible to restore consistency while the last content file to be deleted remains properly without being deleted. is there.
Further, when the process is interrupted in the procedure 6, the information for managing the content file to be deleted may be lost on the file system management information. In this case, matching is obtained with the content file that was the last deletion target being properly deleted. In this case, a negative determination result is obtained in step S316, and the process of this figure is exited without executing the process of restoring consistency.

Subsequently, a modified example related to the present embodiment described so far will be described.
FIG. 12 shows a processing procedure according to the content file operation, which is a modification of the present embodiment. The content file operation in this case is file additional recording in the same manner as in FIG. 12A, 12B, 12C, and 12D have the same contents as FIGS. 7A, 7B, 7C, and 7D.
As a modified example, as shown in FIG. 12E, sub-status information is provided, and when the content file is operated, the sub-status information is also changed.
The sub status information has an auxiliary function to the status information (upper processing layer side status information and lower processing layer side status information) described in the above embodiments, and the digital video of the present embodiment. In the camera 1, the bright memory is to be held in the nonvolatile memory 12a. In addition, the management file control system performs the rewriting operation on the sub status information.

  The sub-status information is set to indicate the contents of “consistency” until the “steady” state in the procedure 1, but is changed to indicate “inconsistency” at the timing of shifting to the procedure 2. . Until the procedure 6 is completed, the content of the “inconsistency” is maintained, and the content indicating the “matching” is returned at the timing of shifting to the procedure 7. In other words, this sub-status information is a period during which a series of processing for processing at the file system level according to file operations and updating of the management file and the backup file are executed from steps 2 to 6. Corresponding to the information, the information is set to indicate “inconsistency”.

  FIG. 13 shows the processing procedure of FIG. 12 as processing between layers of the application, the management file control system, and the file system. In this figure, the same steps as those in FIG. 8 are denoted by the same step symbols, description thereof will be omitted, and only differences from FIG. 8 will be described.

  Depending on step S101, the application requests the management file control system to record the content file. In the case of the procedure of FIG. 8, in response to this request, the management file control system makes a request for creating a content file to the file system in step S106, but here, in step S106 Prior to the above procedure, in steps S105-1 and S105-2 (responses), the sub-status information is changed from the content that has been previously “matched” to the content that indicates “inconsistency”. .

  Further, in the procedure of FIG. 8, the management file control system, after completing the process of rewriting the status information on the lower processing layer side from “backup abnormal” to “consistent” in steps S120 and S121 (response), A process of changing the sub status information so as to return it from the “unmatched” to the “matched” is executed by S121-1, S121-2 (response), and at the timing when this process is finished, step S122 is performed. Thus, a response to the backup file update request is returned to the application.

  The flowchart of FIG. 14 shows a processing procedure for restoring consistency at the time of activation for a modified example in which substatus information is provided as described above. Since steps S401 to S417 shown in this figure are the same as steps S101 to S117 shown in FIG. 11, the description thereof is omitted here.

In the processing procedure of FIG. 14, a determination process is first provided as step S400. In step S400, the sub-status information stored and held in the nonvolatile memory 12a is accessed and the content thereof is referred to to determine whether “match” or “mismatch” is indicated.
The case where the sub status information has the contents of “match” means that the power supply is stopped under the state of procedure 1 or procedure 7 as can be seen from FIGS. . Therefore, the content file management between the management file and the backup file and the file system level is consistent. Therefore, when a determination result of “matching” is obtained in step S400, the process of FIG. 14 is skipped without executing the process for restoring the consistency. On the other hand, if a determination result of “inconsistency” is obtained in step S400, the power supply is stopped in the processing flow from steps 2 to 6. May be in a state that can be regarded as lost ("inconsistency", "management file error", "backup error"). Therefore, the processing after step S401 is executed.

In this way, the sub-status information is used to first determine whether or not there is a need to execute the consistency return processing in step S401 and subsequent steps. The sub status information is information that is to be stored in the nonvolatile memory 12a as described above. On the other hand, the main status information has a structure formed by combining upper processing layer side status information and lower processing layer side status information, and the upper processing layer side status information is stored in the nonvolatile memory 12a. Although it is stored, the status information on the lower processing layer side is stored in the HDD 14.
Since the nonvolatile memory 12a is a semiconductor storage element such as a flash memory that can be directly accessed by the CPU 10 via the internal data bus, for example, its access speed is considerably higher than that of the HDD 14. That is, by first accessing the sub-status information stored in the nonvolatile memory 12a and referring to the contents thereof, it is possible to quickly determine whether or not the process for restoring the consistency should be executed in the course of the startup process. You can do it. Thereby, it becomes more efficient as a starting process, for example, shortening of starting time is also anticipated.

  By the way, the upper processing layer side status information is also stored in the nonvolatile memory 12a, and, for example, “matching” is performed in accordance with steps 1 and 7 in FIG. “Inconsistency” is indicated during the period. In this respect, the upper processing layer side status information is the same as the sub status information. Therefore, for example, in the determination process in step S400 of FIG. 14, it is possible to refer to the upper processing layer side status information. However, it is advantageous to use the sub-status information for the determination process in step S400 of FIG. 14 for the following reason.

As described above with reference to FIG. 13, the content of the upper processing layer side status information is changed by an application operation, and the content of the sub status information is changed by the management file control system.
The timing for changing the status information of the upper processing layer by the application from “consistent” to “inconsistent” or the timing to change from “inconsistent” to “consistent” issuance of a content file recording request at the application level ( S101) Based on the timing and the response reception timing returned from the lower processing layer in response to this request.
On the other hand, the change timing from “consistent” to “inconsistent” or the timing to change from “inconsistent” to “consistent” for the sub-status information by the management file control system is the content file creation request ( S106) or the timing of the backup file update process (S118). That is, the content of the sub status information is changed according to the processing timing at a level closer to the physical layer than the application. Therefore, when the timing of content change between the upper processing layer side status information and the sub status information is compared, the sub status information corresponds to the flow of the procedure shown in FIG. It is closer to the actual processing timing and it can be said that the reliability is high. Therefore, higher reliability can be expected as the determination result by using the sub-status information in the determination of whether or not the consistency return process is possible in step S400.

Subsequently, the backup file rewriting process in the present embodiment will be described.
In this embodiment, as shown in FIG. 15, the management file that is the original of the backup file is handled as a set of blocks in a predetermined fixed length. Similarly, as shown in FIG. 15, the backup file is also formed by a set of blocks.
In this figure, logical numbers from 0 to N are given to the blocks forming the management file and the backup file. In the case of the present embodiment, a block is a unit obtained by collecting a predetermined number of clusters, which is a management unit of the file system.

Here, as shown in the figure, it is assumed that data update has been performed on a part of block 1, a part of block 2, and a part of block 4 (two locations) in the management file. In order to reflect the contents of the management file updated in this way in the backup file, the block in which the data portion has been updated (update block) is overwritten and copied to the same block number in the block structure of the backup file. To be done.
For example, as the rewriting process for reflecting the updated contents of the management file in the backup file, all data forming the management file may be simply copied to the structure of the backup file. Such an algorithm may be simple in the algorithm, but is not efficient in that a data portion that has not been updated is always copied. In particular, as the size of the management file increases, the time required for copying increases and the processing speed decreases.
On the other hand, as described with reference to FIG. 15, if only the block including the updated data portion is copied, the data of the block not including the updated data portion is not copied. Minimal copy processing is required. As a result, an increase in time required for copying can be suppressed, and an improvement in processing speed can be expected.
Further, since the minimum unit of data rewriting is a block unit, the processing algorithm can be as simple as possible. Further, since there are often cases where a plurality of data update portions are included in one block, by copying one block, a plurality of data update portions can be reflected in the backup file at a time. Good quality is also obtained.

FIG. 16 is a diagram showing an example of a more specific update procedure of the backup file described with reference to FIG. 5 including the storage device access procedure.
In this figure, first, FIG. 16A shows a management file stored in the HDD 14. Also in this figure, the management file (and backup file) is shown by a structure formed in units of blocks.
For example, when the management file is updated according to a content file operation or the like, a data rewrite process for updating is executed on the memory. The memory here is the RAM 12 in correspondence with FIG. Therefore, when updating the management file, the management file data is read as shown in FIGS. 16 (a) and 16 (b). That is, from the management file data stored in the HDD 14, the data portion required for the current update is read in block units and copied so as to be written in the memory. Then, as shown in FIG. 16C, the management file is updated on this memory. In FIG. 16C, the same update contents as in FIG. 15A are shown. When the update of the management file data in the memory is completed in this way, the management file is written as shown in the flow from FIG. 15C to FIG. 15D. That is, the block data whose contents are updated in the memory is written again so as to be copied to the management file structure of the HDD 14. By completing this stage, the management file has been updated.

When the management file is updated, the backup file is updated so that the contents are reflected. For this purpose, as shown in the flow of processing from FIG. 16D to FIG. 16E, data for backup is read. That is, only the updated block is read from the management file stored in the HDD 14 in the updated state as shown in FIG. 16D, and copied to the memory (see FIG. 16E). Write).
Then, as shown as a transition from FIG. 16E to FIG. 16F, the backup file is written. That is, writing is performed by copying the updated block data held in the memory to the target block of the backup file stored in the HDD 14.

FIG. 17 shows another example of the backup file update procedure of the present embodiment.
First, the flow of processing as shown in FIGS. 17A, 17B, 17C, and 17D is the same as in FIGS. 16A, 16B, 16C, and 16D. That is, first, data required for updating is read from the management file stored in the HDD 14 in units of blocks and copied onto the memory (reading of the management file). Then, the data held in the memory is updated (data rewriting) according to the file operation result, and the updated block unit data is written and stored in the HDD 14.

Then, in order to update the backup file so that the contents are reflected in accordance with the update of the management file described above, the procedures of FIGS. 17E and 17F are performed.
That is, after the management file is updated on the memory as shown in FIG. 17C, the update is performed as shown as a transition from FIG. 17C to FIG. 17E. The block unit data is further copied and stored in another area on the same memory. Then, as shown as a transition from FIG. 17E to FIG. 17F, the block unit data copied in the memory for this backup is copied to the target block of the backup file stored in the HDD 14. By writing in this way, the backup file is written out.

By using the procedure shown in FIG. 17, the backup file can be updated more efficiently and faster than the procedure shown in FIG. 16. That is, in FIG. 16, the updated block is read by accessing the HDD 14 in order to read the data for backup shown as the transition from FIG. 16 (d) to FIG. 16 (e). On the other hand, in the procedure of FIG. 17, as shown in the procedures of FIGS. 17C and 17E, the difference data for backup is prepared by copying the block data updated in the memory. Therefore, the procedure for accessing and reading the differential data for backup by accessing the HDD 14 becomes unnecessary.
In this way, in the procedure shown in FIG. 17, one procedure for accessing the HDD 14 and reading data is omitted as compared with FIG. At present, the access time to the HDD or the like is considerably longer than the access time to a semiconductor memory device such as a RAM or a flash memory. On the other hand, in FIG. 17, the updated block data is copied to the memory for backup according to FIGS. 17C and 17D, but this processing is processing on the same memory (RAM). Therefore, it is a short time compared with the access to the HDD 14.
In this way, in the procedure of FIG. 17, the time required for the update process of the backup file is shortened by reducing the number of accesses to the HDD 14, and for example, the possibility of a physical failure of the HDD can be expected. For example, efficiency is improved.

Note that the present invention should not be limited to the configuration as the embodiment described so far.
For example, in the embodiment, the information unit as the status information based on the present invention is formed as a composite of at least the upper processing layer side status information and the lower processing layer side status information. It is supposed to be stored in different storage media. For example, if you do not consider the difference in access speed or the efficiency of access to the storage media due to system hierarchy, etc., which storage media will store these status information There is no particular restriction on this. Further, as described above, a structure as substantial status information may be taken by one information unit.
Further, the management mode by the file system for the management file (and backup file), and the format and specification of the management file may be considered other than those described with reference to FIGS. Further, in the above-described embodiment, a content file whose information content is an image, sound, or the like is managed depending on the management file, but the file type that is managed by the management file is not particularly limited. For example, it may be a document file. Further, depending on the actual use of the device, there is a possibility that a specific type of file to be managed by the management file matches all types of files managed by the file system (basic file management means). Accordingly, the device to which the present invention is applied is not limited to a digital video camera, and can be applied to other various devices.

It is a block diagram which shows the structural example of the digital video camera which is an information processing apparatus as embodiment of this invention. It is a figure which shows the example of a management mode of the content file by the file system in this Embodiment, a management file, and a backup file by a directory structure. It is a figure which shows the structural example of a management file typically. 1 is a diagram illustrating a system configuration related to media (HDD) access in a digital video camera according to an embodiment using a hierarchical model. FIG. It is a figure which shows the example of a transition about the consistency of the management state by the file system management information according to content file operation and the management file by the file system according to rewriting, and the management state by a management file. It is a figure which shows the example of a procedure about the file system management according to content file operation, the rewriting of a management file and a backup file, and the transition example about the consistency of the file management state by the file system and management file according to rewriting . It is a figure which shows the example of a procedure about the file system management according to recording operation of a content file, rewriting of a management file, and a backup file, and the transition example about the status information according to rewriting. It is a figure which shows the example of a procedure about rewriting of the file system management according to the recording operation of a content file, a management file, and a backup file as a process between system layers. It is a figure which shows the example of a procedure about the file system management according to the deletion operation of a content file, rewriting of a management file, and a backup file, and the transition example about the status information according to rewriting. It is a figure which shows the example of a procedure about rewriting of the file system management according to content file deletion operation, a management file, and a backup file as a process between system layers. 10 is a flowchart illustrating an example of a procedure of processing for restoring consistency between file system management information, a management file, and a backup file when a digital video camera is activated. It is a figure which shows the example of a procedure about the file system management according to the recording operation of a content file, rewriting of a management file, and a backup file, and the transition example about the status information and sub status information according to rewriting. It is a figure which shows the example of a procedure about rewriting of file system management according to recording operation of the content file illustrated in FIG. 12, a management file, and a backup file as a process between system layers. It is a flowchart which shows the example of a procedure of the process for a consistency return between file system management information, a management file, and a backup file in case sub status information is provided. It is a figure which shows the rewrite processing concept of the backup file in embodiment. It is a figure which shows the example of a procedure of the backup file rewriting as embodiment. It is a figure which shows the other example of a procedure about backup file rewriting as embodiment.

Explanation of symbols

  1 digital video camera, 2 optical system unit, 3 photoelectric conversion unit, 4 video signal processing unit, 5 image input / output unit, 6 camera function unit, 7 display unit, 8 audio processing unit, 9 audio input / output unit, 10 CPU, 11 ROM, 12 RAM, 12a Non-volatile memory, 13 Media controller, 14 HDD, 15 Operation input part, 16 Communication part

Claims (8)

Basic file management means for managing files stored in a storage medium;
Specific file management means for managing a specific type of file in the file managed by the basic file management means using specific file management information managed in units of files by the basic file management means;
A backup that is processed in units of files by the basic file management means and performs processing for a backup file that has information contents that reflect the contents of the specific file management information in order to back up the specific file management information File processing means;
The basic file management includes processing according to a predetermined procedure for changing the file management content by the basic file management means and rewriting the specific file management information and the backup file according to the processing related to the specific type of file. Update control means for controlling to be executed by the means, the specific file management means, and the backup file processing means,
Indicates the state of management of the specific type of file by the basic file management means, the state of the specific file management information and the content of the backup file, and status information to be stored and held in a predetermined nonvolatile storage area , Status information processing means for changing according to the progress of the procedure when the update process by the update control means is being executed;
An information processing apparatus comprising: The status information includes an information unit as first status information and an information unit as second status information.
The status information processing means includes
Processing for the specific type of file is performed, file processing means for changing the first status information in accordance with this processing, and second status information in accordance with the timing for updating the management file And the specific file management means for updating
The information processing apparatus according to claim 1. Sub-status information processing means for processing the sub-status information stored in a predetermined nonvolatile storage area so that the status information is used as main status information and can be accessed at a higher speed than the main status information. With
The sub-status information processing means, at a timing according to the update process of the specific file management information by the specific file management means, the management content of the specific type of file by the basic file management means, the specific file management information, and the The content of the sub status information is changed so as to indicate whether the backup file is consistent or inconsistent.
The information processing apparatus according to claim 1. The update control means includes
If the process for the specific file type is delete,
Rewriting the specific file management information, rewriting the backup file, and changing the file management content by the basic file management means, in order,
The information processing apparatus according to claim 1. The specific file management means manages the specific file management information as formed by a set of data units of a predetermined size, and the backup file processing means forms the backup file by a set of data units of the predetermined size. After being managed as a thing,
When rewriting the backup file, the update control means executes control so that only the data unit including the data portion rewritten in the specific file management information is copied to the structure of the backup file. ,
The information processing apparatus according to claim 1. The update control means includes
The block data including the data portion that has been rewritten with respect to the specific file management information held in the working memory is copied and held on the same working memory. Rewrite the backup file by copying the block data in the working memory to the backup file structure.
The information processing apparatus according to claim 1. A basic file management procedure for managing files stored in a storage medium;
A specific file management procedure for managing a specific type of file in the file managed by the basic file management procedure using the specific file management information managed in units of files by the basic file management procedure;
A backup that is processed in units of files according to the basic file management procedure, and that processes a backup file that has information contents that reflect the contents of the specific file management information in order to back up the specific file management information File processing procedures;
In accordance with the processing related to the specific type of file, processing according to a predetermined procedure for changing the file management content by the basic file management procedure and rewriting the specific file management information and the backup file is performed by the basic file management. Update control procedure for controlling to be executed by the procedure, the specific file management procedure, and the backup file processing procedure;
Indicates the status of management of the specific type of file by the basic file management procedure, the status of the specific file management information and the content of the backup file, and status information to be stored and held in a predetermined non-volatile storage area A status information processing procedure to be changed according to the progress of the procedure when the update process according to the update control procedure is being executed;
The information processing method characterized by performing. A basic file management procedure for managing files stored in a storage medium;
A specific file management procedure for managing a specific type of file in the file managed by the basic file management procedure using the specific file management information managed in units of files by the basic file management procedure;
A backup that is processed in units of files according to the basic file management procedure, and that processes a backup file that has information contents that reflect the contents of the specific file management information in order to back up the specific file management information File processing procedures;
In accordance with the processing related to the specific type of file, processing according to a predetermined procedure for changing the file management content by the basic file management procedure and rewriting the specific file management information and the backup file is performed by the basic file management. Update control procedure for controlling to be executed by the procedure, the specific file management procedure, and the backup file processing procedure;
Indicates the status of management of the specific type of file by the basic file management procedure, the status of the specific file management information and the content of the backup file, and status information to be stored and held in a predetermined non-volatile storage area A status information processing procedure to be changed according to the progress of the procedure when the update process according to the update control procedure is being executed;
For causing an information processing apparatus to execute the program.

Images