WO2008113921A2 - Procede de gestion de fichiers - Google Patents

Procede de gestion de fichiers Download PDF

Info

Publication number
WO2008113921A2
WO2008113921A2 PCT/FR2008/000177 FR2008000177W WO2008113921A2 WO 2008113921 A2 WO2008113921 A2 WO 2008113921A2 FR 2008000177 W FR2008000177 W FR 2008000177W WO 2008113921 A2 WO2008113921 A2 WO 2008113921A2
Authority
WO
WIPO (PCT)
Prior art keywords
file
locking
data
opening
function
Prior art date
Application number
PCT/FR2008/000177
Other languages
English (en)
Other versions
WO2008113921A3 (fr
Inventor
Alexis Tamas
Amaury Grimbert
Original Assignee
Stg Interactive
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Stg Interactive filed Critical Stg Interactive
Priority to KR1020137029338A priority Critical patent/KR101365861B1/ko
Priority to CA002678186A priority patent/CA2678186A1/fr
Priority to US12/526,724 priority patent/US8504541B2/en
Priority to JP2009548717A priority patent/JP5123318B2/ja
Priority to EP08761876A priority patent/EP2130147A2/fr
Publication of WO2008113921A2 publication Critical patent/WO2008113921A2/fr
Priority to IL200252A priority patent/IL200252A0/en
Publication of WO2008113921A3 publication Critical patent/WO2008113921A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/13—File access structures, e.g. distributed indices
    • G06F16/137—Hash-based
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/40—Data acquisition and logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/176—Support for shared access to files; File sharing support
    • G06F16/1767—Concurrency control, e.g. optimistic or pessimistic approaches
    • G06F16/1774—Locking methods, e.g. locking methods for file systems allowing shared and concurrent access to files

Definitions

  • the present invention relates to the field of digital file management, and more particularly to their recording, playback and modification on a recording medium. More specifically, it relates to a method and a system for managing data files interacting with a file system (file system) specific to the operating system (operating system) of the computer.
  • file system file system
  • operating system operating system
  • a new data file is stored in a location of a memory, for example a hard disk, depending on the availability of memory space.
  • a recording on a hard disk it is organized in blocks initialized at the time of formatting. These blocks are distributed at the time of formatting on the physical sectors of the memory.
  • the management of data files on a computer is performed by the file system of the operating system of the computer.
  • the file system of an operating system implements one or more partitions on a recording medium.
  • a partition includes storage space for storing any data file, and an indexing space in which the storage space characteristics, including the file addresses in the storage space, are stored.
  • Some files are directories, grouping lists of features related to data files and directories belonging to the same partition. For recording media having a large storage volume, for example, several gigabytes, the performance of the file system indexing system is degraded when the number of data files to be recorded, read, or modified becomes important in a system. same directory.
  • the organization of the files of the directory type includes a list containing a very large number of occurrences to be processed, which increases the access time to a file in a crippling manner when the number of data files reaches several tens of times. thousands.
  • This degradation is increased by fragmentation phenomena of directory type files that occur when a data file needs to be renamed or deleted.
  • Another organization known by the Linux EXT3 file system is the organization of directory files with an internal B-Tree indexing system and for each data file the calculation of a condensate of the name. the data file from the result of a hash function, to speed up search in directories containing a large number of data files. This solution makes it possible to exploit several hundreds of thousands of data files in the same directory.
  • patent US5742817 describes a file server, proposing a file consultation method for the purpose of simplifying the processing of the addresses.
  • This document proposes Accelerate access to files by processing the INODE identification assigned automatically by the file management system. This process consists in extracting from this identifier three hexadecimal data to which subdirectories correspond in the filesystem.
  • US2004 / 0236761 discloses a system for saving files in a series of directories and subdirectories. In the last level of a tree, a process is performed consisting of calculating a condensate function of the file name to determine a sub-directory "HASH SLOT" in which said file is recorded.
  • the memory space is organized in a conventional tree form, and at the last level of the tree, a processing determines the subdirectory among a set at a single level.
  • This solution limits the number of files that can be saved.
  • the number of subdirectories is limited by the addressing modes of the file management system, for example 65,536 for a UNIX type management system.
  • the number of files inside each sub-directory referred to above is also limited with the same limit.
  • the capacity is limited, and to fully utilize the capacity, it is necessary to maximize the number of subdirectories which limits the performance of the file management system in this single level of the "rake" of subdirectories.
  • the object of the present invention is to remedy this drawback by proposing a robust and fast file management method, making it possible to exploit a number of data files limited only by the available space of the memory, and not by the treatments performed by the file system on the names of the data files.
  • the solution according to the invention therefore does not limit the capacity to exploit mass storage memories, the only limit being the physical capacity of these memories and no longer the modes of operation proposed by the file system. It can handle very large numbers of data files, for applications such as file servers.
  • the invention relates to a file management method, comprising a first step of organizing the database of data files consisting of creating a directory tree to
  • steps of recording data files consisting of: applying a hash function on the identifier of a data file F 1 to be recorded, determining the path of the directory R di of destination in the multi-level tree according to the result of the previous step, storing the data file in said directory R di determined by said hash function, at a location dependent on the identifier of the data file, and steps of reading data files consisting in: applying the same hash function on the identifier of a data file F 1 to read, determining the path of the directory R cj target in the tree based on the result of the previous step, read the data file in said directory R cj determined by said hash function, at a location according to the identifier of the data file.
  • the invention relates, according to a particular mode of implementation, to a file management method according to the preceding claim characterized in that that the data files are spread over Q storage units, each storage unit corresponding to P directory levels of N directories.
  • the invention assigns by the application of the hash function not a location in a given directory, but a path in a tree having a plurality of levels.
  • the location in the last-level subdirectory is not assigned by the hash function, but by a name associated with the identifier of the data file.
  • N is equal to 16
  • the hash function is the SHAl function.
  • An additional problem of file management is the protection of the integrity of the data in case of simultaneous access to the same data file by two applications. It is known on most operating systems to lock file files at the file system level, temporarily blocking access to a data file being written or read. These solutions are handled by the file system, usually from a residual lock table in memory. The disadvantage of these solutions is that in case of access to a file through a network, interference or errors can occur if access to the same file from a plurality of computers apart.
  • Patent US6850969 proposes a particular solution to avoid the use of locks.
  • This patent proposes a posteriori control of the possibility for an application to record changes in an open data file, and ensures that during this so-called atomic operation no other application has intervened on the same data file.
  • atomic means a set of indivisible tasks executed consecutively without the possibility of interruption or interference by a third operation before the completion of all the tasks of the so-called atomic operation.
  • each data file comprises a header and a body.
  • the header has A status parameters of the data file in the file management system.
  • the body includes the editable contents of the file.
  • the method includes a step of accessing a target data file causing the modification of one of said state parameters to a state prohibiting a new access.
  • FIG. 1 represents a schematic view of the tree implemented by the management method of files according to the invention
  • Figures 2 to 8 show the functional diagrams of the file management
  • FIG. 9 represents the use diagram of the file management system through a network, corresponding to a client-server mode.
  • FIG. 1 represents a schematic view of the tree implemented by the file management method according to the invention.
  • M five levels (1 to 5).
  • Each directory of each level (1 to 4), except the last level (5), contains N 16 directories (10 to 12), (20 to 25), (30 to 35), (40 to 45).
  • the name of each of the 16 directories corresponds to a hexadecimal digit between 0 and f.
  • the total number of directories contained in the structure is 16 + 16 2 +16 3 ... + 16 M.
  • the tree includes:
  • level directories (1 to 4), not containing data files, but only top-level directories; - 1,048,576 directories (50 to 55) of level (5); each directory containing files for storing the data files.
  • Each directory (50 to 55) of the last level (5) may contain a limited number L of data files, L being chosen small, for example of the order of 1,000, to allow a fast access time, and this, whatever the file system of the operating system of the computer.
  • the method When creating a new data file, designated by a unique use name formed by a string, the method consists in applying a hash function H 1 to this character string representing the name of use, the result of which will be a value represented in hexadecimal form.
  • H 1 For a SHAl hash function, the result in hexadecimal form will consist of 40 hexadecimal digits between 0 and f.
  • the method includes determining, in the context of the previously defined directory tree and from this result of the hash function, a directory path in said tree.
  • the rank of each of the first M digits of the result of the hash function will correspond to a level of the directory tree.
  • the directory of level (1) will be the one with the name "b”, corresponding to the first character of the value SHAl, the directory of level (2) will be "3", corresponding to the second character, and so on for the 5 levels (1 to 5).
  • the location in the last directory (5) will consist of the two-digit hexadecimal representation of the bytes of each character constituting the usage name.
  • the file location and name will be "6d7966696c65"
  • 6d is the two-digit hexadecimal representation of the "m” character
  • "79” is the two-digit hexadecimal representation of the character "Y”
  • "66” corresponding to the two-digit hexadecimal representation of the "f” character, and so on.
  • the file name will necessarily be unique because it results from the combination of a location calculated from the hash function and a data file name. calculated uniquely from the usage name.
  • This solution distributes the data files in the M directory of the directory tree equally and with maximum dispersion. Only the M level contains data files, the intermediate levels do not contain any data files and used only for the distribution of files in the M-level directories.
  • each M-level directory the number of data files is reasonable, for example of the order of 1,000, which leads to fast access times.
  • the first step is to determine, based on the file usage name, its path in the tree and its associated file name, by applying the previously mentioned hash function and calculating the name of the file. file from the usage name. This step makes it possible to determine in which directory of level M is recorded the file and its location in this directory.
  • the latter each include a header and a body.
  • the body includes the editable contents of the file, in directly accessible form or in compressed or encrypted form. This body is preceded by a header with file status parameters in the file management system.
  • the access to a file by a treatment results in a first acquisition step of modifying one of said state parameters of the header to a state prohibiting a new access by another processing.
  • a prohibition or waiting notification For the file is being accessed or used by a processing, another processing will encounter, during this initial acquisition step, a prohibition or waiting notification.
  • the other process reiterates this initial acquisition step until the target file is again in a state allowing access, or until a predetermined delay causes the access attempts to be interrupted.
  • a last release step restores the initial state of the modified parameter in the header, thus allowing another process to access the data file.
  • FIGS 2 to 8 show the function structures implemented by the invention.
  • Figure 2 shows the sequence of tasks required to acquire an existing data file.
  • the function takes as input (150) the name of a file calculated from the usage name as explained above.
  • the first task (100) is to attempt simultaneous opening and locking of the file at the operating system file system, requesting an opening and locking of the file preventing until closing and unlocking the opening and locking of this file by a later treatment.
  • the function then performs a test (101) to check the opening and locking of the file: if the file is not opened and locked, the test result
  • a test (104) checks whether the number of attempts (100) exceeds a threshold value, or if the time delay is exceeded, and retries (100) after a delay (149) in case of negative response ; otherwise, the function returns a system error (105).
  • the function If the result of the test (101) is positive, the function reads the state of availability of the file in a state parameter of the file header during a task (106). The function then performs a file availability test (107) based on the value of the state parameter.
  • the function proceeds to a task (108) of simultaneous closing and unlocking of the file at the level of the file system of the operating system.
  • the function then performs a test (109) which checks whether the number of attempts (100) exceeds a threshold value, or if the time delay is exceeded, and retries (100) after a timer (149) in the event of a response. negative; otherwise, the function returns an error
  • the function performs a task (111) of writing the state of unavailability of the file in a state parameter of the file header, and then a task (112) for calculating a file acquisition identifier, a task (113) for writing this identifier in a state parameter of the file header, and a task (114) for reading the file body of the file.
  • the task (115) corresponds to a processing of the file body to extract the editable contents of the file. This processing is performed based on the state settings of the file header. It corresponds for example to decompression or decryption of the editable content of the file.
  • the last task (116) is to simultaneously close and unlock the file at the operating system file system level.
  • the function returns at its completion (151) the confirmation of the acquisition of the data file, the acquisition identifier of the file and the editable contents of the file.
  • Figure 3 shows the sequence of tasks required to acquire a new data file.
  • the function takes as input (250) the name of a file computed from the usage name as explained above.
  • the first task (200) is to attempt to simultaneously create, open, and lock a new file at the operating system file system, requesting creation, opening, and locking of the file to prevent closing and unlocking the opening and locking of this file by posterior processing.
  • the function then proceeds to a test (201) to verify the creation, opening and locking of the file: if the file is not created, opened and locked, the result of the test (201) is negative and the function proceeds.
  • a second test (202) which checks whether the file existed during the attempt (200).
  • the function returns an error (204) indicating that the file already exists.
  • the function In the case of a negative response, the function returns an error (203) indicating a system error.
  • the function proceeds to a task (205) for creating and writing the file header with a body of the empty file, then a task (206) for writing the file. state of unavailability of the file in a state parameter of the header of the file, then a task (207) for calculating a file acquisition identifier, a task (208) for writing this file identifier in a state parameter of the file header.
  • the last task (209) is to simultaneously close and unlock the file at the file system level of the operating system.
  • the function returns at its completion (251) the confirmation of the acquisition of the data file and the acquisition identifier of the file.
  • Figure 4 shows the succession of tasks required to acquire an existing data file with creation of the file if it does not exist.
  • the function takes as input (350) the name of a file computed from the usage name as explained above.
  • the first task (300) is to attempt simultaneous opening and locking of the file at the operating system file system, and to create the file if it does not exist, requesting opening and locking the file preventing until it closes and unlocking the opening and locking of this file by a later processing.
  • the function then performs a test (301) to check the opening and locking of the file: if the file is not opened and locked, the test result
  • a test (302) which checks if the file existed during the attempt (300). In the case of a negative response, the function returns a system error (303). In the case of a positive response, a test (304) checks whether the number of attempts (300) exceeds a threshold value, or if the time delay is exceeded, and retries (300) after a delay (349) in the event of a delay. negative response ; otherwise, the function returns a system error (305).
  • test (301) If the result of the test (301) is positive, the function then proceeds to a test (306) to check whether the file was during the attempt (300): if the file was not created, the test result (306) is negative and the function reads the state of availability of the file in a state parameter of the file header during a task (307).
  • the function then performs a file availability test (308) based on the value of the state parameter. If the result of the test (308) is negative, corresponding to a state of unavailability, the function performs a task (309) of simultaneous closing and unlocking of the file at the level of the file system of the operating system. The function then performs a test (310) which checks whether the number of attempts (300) exceeds a threshold value, or if the time delay is exceeded, and retries (300) after a delay (349) in case of response. negative; otherwise, the function returns an error (311) indicating that the file remains acquired by a current process.
  • the function performs a task (312) of writing the state of unavailability of the file in a state parameter of the file header, and then a task (313) for calculating a file acquisition identifier, a task (314) for writing this identifier in a state parameter of the file header, and a task (315) for reading the file body of the file.
  • the task (316) corresponds to a processing of the body of the file to extract the modifiable contents of the file. This processing is performed based on the state settings of the file header. It corresponds for example to decompression or decryption of the editable content of the file.
  • the task (317) is to simultaneously close and unlock the file at the file system level of the operating system.
  • the function returns at its completion (351) the confirmation of the acquisition of the data file, a notification that the file has not been created, the acquisition identifier of the file and the editable content of the file.
  • the function proceeds to a task (318) of creating and writing the file header with an empty file body, then a writing task (319) the state of unavailability of the file in a state parameter of the file header, then a task (320) for calculating a file acquisition identifier, a writing task (321) of this identifier in a state parameter of the file header.
  • the last task (322) is to simultaneously close and unlock the file at the operating system file system level.
  • the function returns at its completion (352) the confirmation of the acquisition of the data file, a notification that the file has been created and the acquisition identifier of the file.
  • Figure 5 shows the succession of tasks required for the release of a data file acquired without modification of the data.
  • the function takes as input (450) the name of a file calculated from the usage name as explained above and an acquisition identifier returned during a previous acquisition of the data file.
  • the first task (400) is to attempt simultaneous opening and locking of the file at the operating system file system, requesting an opening and locking of the file preventing until it is closed and unlocked. opening and locking this file by subsequent processing.
  • the function then carries out a test (401) to check the opening and locking of the file: if the file is not opened and locked, the result of the test (401) is negative and the function carries out a second test ( 402) which checks if the file existed during the attempt (400). In the case of a negative response, the function returns an error (403) indicating that the file does not exist. In the case of a positive response, a test (404) checks whether the number of attempts (400) exceeds a threshold value, or if the time delay is exceeded, and retries (400) after a delay (449) in case of negative response ; otherwise, the function returns a system error (405).
  • the function If the result of the test (401) is positive, the function reads the state of availability of the file in a state parameter of the file header during a task (406). The function then performs a file availability test (407) based on the value of the state parameter.
  • the function performs a task (408) of simultaneous closing and unlocking of the file at the operating system file system level and returns an error (409) indicating that the file is not acquired.
  • the function reads the acquisition identifier in the header of the file during a task (410).
  • the function then performs a test (411) which checks whether this identifier is different from the inputted identifier. In the case of a positive response, the function performs a simultaneous closing and unlocking task (412) of the file at the file system level of the operating system and returns an error (413) indicating that the acquisition identifier submitted in input is not valid. In the case of a negative response, the function performs a task (414) of erasure of the acquisition identifier in the state parameter of the header of the file, then a task (415) of writing of the availability status in the file header. The last task (416) is to close and simultaneously unlock the file at the operating system file system level.
  • the function returns at its completion (451) the confirmation of the release of the data file.
  • Figure 6 shows the sequence of tasks required for the release of a data file acquired with modification of the data.
  • the function takes as input (550) the name of a file calculated from the usage name as explained above, an acquisition identifier returned during a previous acquisition of the data file and the modifiable content of the file.
  • the first task (500) is to attempt simultaneous opening and locking of the file at the operating system file system, requesting an opening and locking of the file preventing until it is closed and unlocked. opening and locking this file by subsequent processing.
  • the function then performs a test (501) to check the opening and locking of the file: if the file is not opened and locked, the test result
  • a test (504) checks whether the number of attempts (500) exceeds a threshold value, or if the time delay is exceeded, and retries (500) after a delay (549) in the event of negative response ; otherwise, the function returns a system error (505).
  • the function reads the state of availability of the file in a state parameter of the file header during a task (506).
  • the function then performs a file availability test (507) based on the value of the state parameter.
  • the function performs a simultaneous closing and unlocking task (508) of the file at the operating system file system level and returns an error (509) indicating that the file is not acquired.
  • the function reads the acquisition identifier in the header of the file during a task (510).
  • the function then performs a test (511) which checks whether this identifier is different from the identifier submitted as input. In the case of a positive response, the function performs a simultaneous closing and unlocking task (512) of the file at the operating system file system level and returns an error (513) indicating that the acquisition identifier submitted in input is not valid.
  • the function performs a task (514) for erasing the acquisition identifier in the state parameter of the header of the file, then a task (515) for writing the the state of availability in the file header, then a task (516) corresponding to a processing of the file body to insert the editable content of the file.
  • This processing is done according to the state parameters of the header of the file and corresponds for example to a compression or an encryption of the contents editable file.
  • the function then performs a file body write task (517) and the last task (518) is to simultaneously close and unlock the file at the operating system file system level.
  • the function returns at its completion (551) the confirmation of the release of the data file and the modification of the contents of the file.
  • Figure 7 shows the succession of tasks necessary for the release of a data file acquired with deletion of the file.
  • the function takes as input (650) the name of a file computed from the usage name as explained above and an acquisition identifier returned during a previous acquisition of the data file.
  • the first task (600) is to attempt simultaneous opening and locking of the file at the operating system file system, requesting an opening and locking of the file preventing until it is closed and unlocked. opening and locking this file by subsequent processing.
  • the function then performs a test (601) to check the opening and locking of the file: if the file is not opened and locked, the result of the test (601) is negative and the function carries out a second test ( 602) which checks whether the file existed during the attempt (600). In the case of a negative response, the function returns an error (603) indicating that the file does not exist. In the case of a positive response, a test (604) checks whether the number of attempts (600) exceeds a threshold value, or if the time delay is exceeded, and retries (600) after a timer (649) in case of negative response ; otherwise, the function returns a system error (605).
  • the function If the result of the test (601) is positive, the function reads the state of availability of the file in a state parameter of the file header during a task (606). The function then performs a file availability test (607) based on the value of the state parameter.
  • the function performs a task (608) of simultaneous closing and unlocking of the file at the operating system file system level and returns an error (609) indicating that the file is not acquired.
  • the function reads the acquisition identifier in the header of the file during a task (610).
  • the function then performs a test (611) which checks whether this identifier is different from the inputted identifier. In the case of a positive response, the function performs a simultaneous closing and unlocking task (612) of the file at the operating system file system level and returns an error (613) indicating that the acquisition identifier submitted in input is not valid. In the case of a negative response, the function performs a task (614) for erasing the acquisition identifier in the state parameter of the file header, then a task (615) for writing the the availability status in the file header. The last task (616) is to close, Unlock and delete the file at the operating system file system simultaneously.
  • the function returns at its completion (651) the confirmation of the release of the data file and its erasure.
  • Figure 8 shows the succession of tasks necessary for the simple reading of an existing data file without acquisition of the file.
  • the function takes as input (750) the name of a file calculated from the usage name as explained above.
  • the first task (700) is to attempt simultaneous opening and locking of the file at the operating system's file system, requesting an opening and locking of the file preventing it until it is closed and unlocked. opening and locking this file by subsequent processing.
  • the function then proceeds to a test (701) to check the opening and locking of the file: if the file is not opened and locked, the result of the test (701) is negative and the function carries out a second test ( 702) which checks whether the file existed during the attempt (700). In the case of a negative response, the function returns an error (703) indicating that the file does not exist.
  • a test (704) checks whether the number of attempts (700) exceeds a threshold value, or if the time delay is exceeded, and retries (700) after a delay (749) in case of negative response ; otherwise, the function returns a system error (705). If the result of the test (701) is positive, the function reads the state of availability of the file in a state parameter of the file header during a task (706).
  • the function then performs a file availability test (707) based on the value of the state parameter.
  • the function performs a task (708) of simultaneous closing and unlocking of the file at the file system level of the operating system.
  • the function then performs a test (709) which checks whether the number of attempts (700) exceeds a threshold value, or if the time delay is exceeded, and retries (700) after a delay (749) in case of response. negative; otherwise, the function returns an error (710) indicating that the file remains acquired by a current process.
  • the function performs a task (711) for reading the body of the file, then a task (712) for processing the body of the file to extract the editable content of the file. This processing is performed according to the state parameters of the file header. It corresponds for example to decompression or decryption of the editable content of the file.
  • the last task (713) is to simultaneously close and unlock the file at the file system level of the operating system.
  • the function returns at its completion (751) the confirmation of the simple reading of the data file and the editable contents of the file.
  • Figure 9 relates to a particular and preferred application. It represents the succession of tasks necessary for the use of the file management system according to the invention through a network, corresponding to a client-server mode.
  • the file management system is installed on a server computer (800) that includes server software (801).
  • the server computer is accessible by a plurality of client computers (802 to 804) that each include client software (805 to 807).
  • the exchanges between the client software and the server software use a known type of transport network protocol, for example HTTP or preferably a secure HTTPS protocol.
  • the invention implements an application protocol (808) making it possible to call the functions of the file management system according to the invention by commands of the "file acquisition" or "file release” type.
  • the files are distributed at the level of the server computer in several subsets (809 to 811), each subset corresponding to a tree structure according to the invention, called “table".
  • the usage name of the data file is referred to in the protocol as "key”.
  • the first task (812) is executed on one of the client computers by the client software. It consists in calling a function of acquisition, liberation or simple reading on a table and a key.
  • the second task (813) is performed by the server software on the server computer. It consists of executing the function requested by the client software.
  • the third task (814) is performed by the server software on the server computer. It consists of returning the result of the requested function to the client software.
  • the system has several servers, to distribute the load and the data storage volume.
  • the client software (805 to
  • the server software (801) may also include logging functionalities executed to allow the incremental reconstruction of the server computer's trees on a backup server without performing a complete copy of the trees on the backup server.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un procédé de gestion de fichiers, comportant une première étape d'organisation de la base de fichiers de données consistant à créer une arborescence de répertoires à M niveaux de N répertoires chacun, avec M étant un nombre entier supérieur à 1, et des étapes d'enregistrement de fichiers de données consistant à : appliquer une fonction de hachage sur l'identifiant d'un fichier de données Fi à enregistrer déterminer le chemin du répertoire Rdi à plusieurs niveaux de destination dans l'arborescence en fonction du résultat de l'étape précédente enregistrer le fichier de données dans ledit répertoire Rdidéterminé par ladite fonction de hachage, à un emplacement fonction de l'identifiant du fichier de données et des étapes de lecture de fichiers de données consistant à : appliquer la même fonction de hachage sur l'identifiant d'un fichier de données Fj à lire déterminer le chemin du répertoire Rcj cible dans l'arborescence en fonction du résultat de l'étape précédente lire le fichier de données dans ledit répertoire Rcj déterminé par ladite fonction de hachage, à un emplacement fonction de l'identifiant du fichier de données.

Description

PROCEDE DE GESTION DE FICHIERS
La présente invention concerne le domaine de la gestion de fichiers numériques, et plus particulièrement de leur enregistrement, lecture et modification sur un support d'enregistrement. Plus précisément, elle concerne un procédé et un système de gestion de fichiers de données interagissant avec un système de fichier (file System) propre au système d'exploitation (opérâting System) de 1 ' ordinateur.
D'une manière habituelle, un nouveau fichier de données est enregistré en un emplacement d'une mémoire, par exemple d'un disque dur, en fonction des disponibilités d'espace mémoire. Dans le cas d'un enregistrement sur un disque dur, ce dernier est organisé en blocs initialisés au moment du formatage. Ces blocs sont répartis au moment du formatage sur les secteurs physiques de la mémoire.
La gestion des fichiers de données sur un ordinateur est réalisée par le système de fichier du système d'exploitation de l'ordinateur.
Le système de fichier d'un système d'exploitation met en œuvre une ou plusieurs partitions sur un support d'enregistrement. Une partition comprend un espace de stockage destiné à l'enregistrement de fichiers de données quelconques, et un espace d'indexation dans lequel sont enregistrées les caractéristiques de l'espace de stockage, notamment les adresses des fichiers dans l'espace de stockage . Certains fichiers constituent des répertoires, regroupant des listes de caractéristiques relatives à des fichiers de données et à des répertoires appartenant à une même partition. Pour des supports d'enregistrement ayant un volume de stockage de taille élevée, par exemple plusieurs gigaoctets, les performances du système d'indexation du système de fichier sont dégradées lorsque le nombre de fichiers de données à enregistrer, lire ou modifier devient important dans un même répertoire. En effet, l'organisation des fichiers de type répertoire comprend une liste contenant un nombre très élevé d'occurrences à traiter, ce qui augmente le temps d'accès à un fichier de manière rédhibitoire lorsque le nombre de fichiers de données atteint plusieurs dizaines de milliers. Cette dégradation est augmentée par les phénomènes de fragmentations des fichiers de type répertoire se produisant lorsqu'un fichier de données doit être renommé ou effacé. Un autre mode d'organisation connu par le système de fichier Linux EXT3 propose une organisation des fichiers de type répertoire comprenant un système d'indexation interne de type B-Tree et, pour chaque fichier de données, le calcul d'un condensât du nom du fichier de données à partir du résultat d'une fonction de hachage, pour accélérer la recherche dans les répertoires contenant un nombre important de fichiers de données. Cette solution permet d'exploiter plusieurs centaines de milliers de fichiers de données dans un même répertoire. Toutefois, au-delà d'un certain seuil, les limites de la fonction de hachage ne permettent plus d'éviter des collisions conduisant à l'attribution d'un même condensât à deux fichiers de données de noms distincts. Pour le système de fichier EXT3, cette limite apparaît dès que le nombre de fichiers de données atteint environ 500.000 dans un même répertoire, pour des versions du noyau Linux 2.6.
On connaît dans l'état de la technique le brevet US5742817 décrivant un serveur de fichier, proposant un procédé de consultation de fichiers ayant pour but de simplifier le traitement des adressages. Ce document propose d'accélérer l'accès aux fichiers par un traitement de l'identification INODE attribué automatiquement par le système de gestion de fichiers. Ce traitement consiste à extraire de cet identifiant trois données hexadécimales auxquelles correspondent des sous-répertoires dans le système de fichiers.
La demande de brevet américain US2004/0236761 décrit un système d'enregistrement de fichiers dans une série de répertoires et de sous-répertoires. Dans le dernier niveau d'une arborescence, on procède à un traitement consistant à calculer un condensât fonction du nom du fichier pour déterminer un sous-répertoire « HASH SLOT » dans lequel ledit fichier est enregistré.
En d'autre terme, l'espace mémoire est organisé sous forme classique d'arborescence, et, au dernier niveau de l'arborescence, un traitement détermine le sous-répertoire parmi un ensemble à un seul niveau.
Cette solution limite le nombre de fichiers pouvant être enregistrés. Le nombre de sous-répertoires est limité par les modes d'adressage du système de gestion de fichiers, par exemple 65.536 pour un système de gestion de type UNIX.
De plus, le nombre de fichiers à l'intérieur de chaque sous-répertoire susvisé est également limité avec la même limite . En résumé, la capacité est limitée, et pour utiliser pleinement la capacité, il est nécessaire de maximiser le nombre de sous-répertoires ce qui limite les performances du système de gestion de fichiers dans ce seul niveau du « râteau » de sous-répertoires. Le but de la présente invention est de remédier à cet inconvénient en proposant un procédé de gestion de fichiers robuste et rapide, permettant d'exploiter un nombre de fichiers de données limité uniquement par l'espace disponible de la mémoire, et non pas par les traitements effectués par le système de fichier sur les noms des fichiers de données. La solution selon l'invention ne limite donc pas la capacité d'exploiter des mémoires de stockage de masse, la seule limite étant la capacité physique de ces mémoires et non plus les modes d'exploitation proposés par le système de fichier. Elle permet de gérer de très grands nombres de fichiers de données, pour des applications telles que des serveurs de fichiers .
Selon son acception la plus générale, l'invention concerne un procédé de gestion de fichiers, comportant une première étape d'organisation de la base de fichiers de données consistant à créer une arborescence de répertoires à
M niveaux de N répertoires chacun, avec M étant un nombre entier supérieur à 1, et des étapes d'enregistrement de fichiers de données consistant à : appliquer une fonction de hachage sur l'identifiant d'un fichier de données F1 à enregistrer, déterminer le chemin du répertoire Rdi de destination dans l'arborescence à plusieurs niveaux en fonction du résultat de l'étape précédente, enregistrer le fichier de données dans ledit répertoire Rdi déterminé par ladite fonction de hachage, à un emplacement fonction de l'identifiant du fichier de données, et des étapes de lecture de fichiers de données consistant à : appliquer la même fonction de hachage sur l'identifiant d'un fichier de données F1 à lire, déterminer le chemin du répertoire Rcj cible dans l'arborescence en fonction du résultat de l'étape précédente, lire le fichier de données dans ledit répertoire Rcj déterminé par ladite fonction de hachage, à un emplacement fonction de l'identifiant du fichier de données. Pour utiliser des unités de stockage en parallèle et améliorer les performances (vitesse d'accès et/ou volume de mémoire), l'invention concerne selon un mode particulier de mise en œuvre un procédé de gestion de fichiers selon la revendication précédente caractérisé en ce que les fichiers de données sont répartis sur Q unités de stockage, chaque unité de stockage correspondant à P niveaux de répertoires de N répertoires.
Contrairement à l'enseignement de la demande de brevet US2004/0236761, cette solution conduit à restreindre le nombre de répertoires à chaque niveau de l'arborescence, ce qui permet d'améliorer les performances et notamment la vitesse d'accès aux fichiers de données dans une arborescence à deux dimensions et de rendre quasiment illimité le nombre de fichiers de données susceptibles d'être enregistrés. La limitation n'est plus dépendante des limitations du système de gestion de fichiers, mais seulement par les capacités physiques du moyen de stockage.
Contrairement à cette solution de l'art antérieur, l'invention attribue par l'application de la fonction de hachage non pas un emplacement dans un répertoire donné, mais un chemin dans une arborescence présentant une pluralité de niveaux. L'emplacement dans le sous-répertoire de dernier niveau n'est pas attribué par la fonction de hachage, mais par un nom associé à l'identifiant du fichier de données .
Avantageusement, N est égal à 16, et la fonction de hachage est la fonction SHAl. Un problème complémentaire de la gestion des fichiers concerne la protection de l'intégrité des données en cas d'accès simultanés au même fichier de données par deux applications . II est connu sur la plupart des systèmes d'exploitation de procéder à des verrouillages des fichiers de données au niveau du système de fichier, permettant d'interdire momentanément l'accès à un fichier de données en cours d'écriture ou de lecture. Ces solutions sont gérées par le système de fichier, généralement à partir d'une table de verrouillage résiduelle en mémoire. L'inconvénient de ces solutions est qu'en cas d'accès à un fichier au travers d'un réseau, des interférences ou des erreurs peuvent se produire en cas d'accès à un même fichier à partir d'une pluralité d'ordinateurs distants.
Le brevet US6850969 propose une solution particulière permettant d'éviter l'utilisation de verrouillages. Ce brevet propose un contrôle a posteriori de la possibilité pour une application d'enregistrer des modifications dans un fichier de données ouvert, et garantit que pendant cette opération dite atomique aucune autre application n'est intervenue sur le même fichier de données. On entendra par atomique au sens du présent brevet un ensemble de tâches indivisibles exécutées de manière consécutive sans possibilités d'interruption, ni d'interférence par une opération tierce, avant l'achèvement de la totalité des tâches de l'opération dite atomique.
Cette solution n'est pas satisfaisante car elle empêche l'aboutissement de certaines opérations lorsque plusieurs applications effectuent des traitements au même moment sur un ensemble de fichiers en commun. Elle permet certes d'éviter l'altération des fichiers de données existants, mais au détriment d'un accès concurrent et sécurisé. En effet, cette solution impose que chaque traitement intervienne après que le précédent soit achevé. Elle n'est donc pas réellement adaptée à des traitements sur des fichiers contenant par exemple des données au format XML et qui peuvent être utilisés à tout moment par différentes applications concurrentes .
À cet effet, l'invention concerne également un procédé de gestion de fichiers caractérisé en ce que chaque fichier de données comporte un en-tête et un corps. L 'en-tête comporte A paramètres d'état du fichier de données dans le système de gestion de fichiers . Le corps comprend le contenu modifiable du fichier. Le procédé comporte une étape d'accès à un fichier de données cible provoquant la modification d'un desdits paramètres d'état vers un état interdisant un nouvel accès .
La gestion de ces fichiers de données est indépendante du système de fichier du système d'exploitation de l'ordinateur. L'invention sera mieux comprise à la lecture de la description qui suit, correspondant à des exemples non limitatifs de réalisation, se référant aux dessins annexés où : la figure 1 représente une vue schématique de l'arborescence mise en œuvre par le procédé de gestion de fichiers selon l'invention, les figures 2 à 8 représentent les schémas fonctionnels de la gestion des fichiers,
- la figure 9 représente le schéma d'utilisation du système de gestion de fichiers à travers un réseau, correspondant à un mode client-serveur.
La figure 1 représente une vue schématique de l'arborescence mise en œuvre par le procédé de gestion de fichiers selon l'invention.
Les fichiers de données sont organisés selon une structure subdivisée, dans l'exemple décrit, en M = cinq niveaux (1 à 5 ) . Chaque répertoire de chaque niveau (1 à 4 ) , hormis le dernier niveau (5), contient N = 16 répertoires (10 à 12), (20 à 25), (30 à 35), (40 à 45). Le nom de chacun des 16 répertoires correspond à un chiffre hexadécimal entre 0 et f. Le nombre total de répertoires contenus dans la structure est de 16+162+163...+16M.
Dans l'exemple décrit, l'arborescence comprend :
69.904 répertoires de niveau (1 à 4), ne contenant pas de fichiers de données, mais seulement des répertoires du niveau supérieur ; - 1.048.576 répertoires (50 à 55) de niveau (5) ; chaque répertoire contenant des fichiers permettant de stocker les fichiers de données.
Chaque répertoire (50 à 55) du dernier niveau (5) peut contenir un nombre L limité de fichiers de données, L étant choisi petit, par exemple de l'ordre de 1.000, pour permettre un temps d'accès rapide, et ce, quel que soit le système de fichier du système d'exploitation de 1 ' ordinateur .
Attribution d'un emplacement mémoire à un fichier de données
Lorsque l'on procède à la création d'un nouveau fichier de données, désigné par un nom d'usage unique formé par une chaîne de caractères, le procédé consiste à appliquer une fonction de hachage H1 sur cette chaîne de caractères représentant le nom d'usage, dont le résultat sera constitué par une valeur représentée sous une forme hexadécimale. Pour une fonction de hachage SHAl, le résultat sous forme hexadécimale comprendra 40 chiffres hexadécimaux entre 0 et f.
Le procédé consiste à déterminer, dans le contexte de l'arborescence de répertoires précédemment définie et à partir de ce résultat de la fonction de hachage, un chemin de répertoire dans ladite arborescence. Le rang de chacun des M premiers chiffres du résultat de la fonction de hachage correspondra à un niveau de l'arborescence de répertoires.
Si on prend un exemple de nom d'usage « myfile », l'application de la fonction SHAl retourne la valeur « b3580ab45cb088ba47ff070aa81c2daelbe56ca2 ».
Le répertoire du niveau ( 1 ) sera celui portant le nom « b », correspondant au premier caractère de la valeur SHAl, le répertoire du niveau (2) sera « 3 », correspondant au second caractère, et ainsi de suite pour les 5 niveaux (1 à 5). L'emplacement dans le dernier répertoire (5) sera constitué par la représentation hexadécimale à deux chiffres des octets de chacun des caractères constituant le nom d'usage. Pour le nom « myfile », l'emplacement et le nom du fichier seront « 6d7966696c65 », « 6d » correspondant à la représentation hexadécimale à deux chiffres du caractère « m », « 79 » correspondant à la représentation hexadécimale à deux chiffres du caractère « y », « 66 » correspondant à la représentation hexadécimale à deux chiffres du caractère « f », et ainsi de suite.
Pour des caractères nécessitant un codage sur plusieurs octets, l'ensemble des octets sera successivement représenté sous cette forme.
En raison de l'unicité du nom d'usage du fichier de données, la désignation du fichier sera nécessairement unique car elle résulte de la combinaison d'un emplacement calculé à partir de la fonction de hachage et d'un nom de fichier de données calculé de façon unique à partir du nom d'usage. Cette solution permet de répartir de manière équiprobable et avec une dispersion maximale les fichiers de données dans les répertoires de niveau M de l'arborescence de répertoires. Seul le niveau M contient des fichiers de données, les niveaux intermédiaires ne contenant pas de fichiers de données et servant uniquement à la répartition des fichiers dans les répertoires de niveau M.
À l'intérieur de chaque répertoire de niveau M, le nombre de fichiers de données est raisonnable, par exemple de l'ordre de 1.000, ce qui conduit à des temps d'accès rapides. Le nombre maximum de fichiers de données qui peut être créé dans une arborescence de niveau M est égal à 1.000 x 16M. Par exemple, pour M = 5, il est possible de créer, écrire ou lire environ 1 milliard de fichiers de données dans une arborescence de répertoires de niveau M.
Création, écriture, lecture et effacement d'un fichier de données
La première étape consiste à déterminer, à partir du nom d'usage du fichier, son chemin d'accès dans l'arborescence ainsi que son nom de fichier associé, par application de la fonction de hachage précédemment mentionnée et par le calcul du nom du fichier à partir du nom d'usage. Cette étape permet de déterminer dans quel répertoire de niveau M est enregistré le fichier et son emplacement dans ce répertoire.
Accès concurrent à un même fichier de données
Pour permettre une gestion sécurisée des accès aux fichiers de données, ces derniers comprennent chacun un entête et un corps. Le corps comprend le contenu modifiable du fichier, sous une forme directement accessible ou sous forme compressée ou chiffrée. Ce corps est précédé d'un en-tête comportant des paramètres d'état du fichier dans le système de gestion de fichiers.
De manière systématique, l'accès à un fichier par un traitement, pour une série d'opérations quelconques (écriture, lecture, modification ou effacement), se traduit par une première étape d'acquisition consistant à modifier un desdits paramètres d'état de l' en-tête vers un état interdisant un nouvel accès par un autre traitement. Bien entendu, lorsque le fichier est en cours d'accès ou d'utilisation par un traitement, un autre traitement rencontrera, lors de cette étape initiale d'acquisition, une notification d'interdiction ou d'attente.
L'autre traitement réitère cette étape initiale d'acquisition jusqu'à ce que le fichier cible soit de nouveau dans un état autorisant l'accès, ou jusqu'à ce qu'un délai prédéterminé provoque l'interruption des tentatives d' accès .
Une fois la série d'opérations achevée par le traitement, une dernière étape de libération restaure l'état initial du paramètre modifié dans l'en—tête, permettant ainsi à un autre traitement d'accéder au fichier de données.
Les figures 2 à 8 représentent les structures de fonctions mises en œuvre par l'invention.
Fonction d'acquisition d'un fichier de données existant
La figure 2 représente la succession de tâches nécessaires pour l'acquisition d'un fichier de données existant.
La fonction prend en entrée (150) le nom d'un fichier calculé à partir du nom d'usage comme exposé précédemment. La première tâche (100) consiste à tenter l'ouverture et le verrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation, en demandant une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
La fonction procède ensuite à un test (101) pour vérifier l'ouverture et le verrouillage du fichier : si le fichier n'est pas ouvert et verrouillé, le résultat du test
(101) est négatif et la fonction procède à un deuxième test
(102) qui vérifie si le fichier existait lors de la tentative (100). En cas de réponse négative, la fonction renvoie une erreur (103) indiquant que le fichier n'existe pas.
En cas de réponse positive, un test (104) vérifie si le nombre de tentatives (100) dépasse une valeur seuil, ou si le délai temporel est dépassé, et engage une nouvelle tentative (100) après une temporisation (149) en cas de réponse négative ; sinon, la fonction retourne une erreur système ( 105) .
Si le résultat du test (101) est positif, la fonction lit l'état de disponibilité du fichier dans un paramètre d'état de l'en-tête du fichier lors d'une tâche (106). La fonction procède ensuite à un test (107) de disponibilité du fichier en fonction de la valeur du paramètre d'état.
Si le résultat du test (107) est négatif, correspondant à un état d'indisponibilité, la fonction procède à une tâche (108) de fermeture et de déverrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation.
La fonction réalise ensuite un test (109) qui vérifie si le nombre de tentatives (100) dépasse une valeur seuil, ou si le délai temporel est dépassé, et engage une nouvelle tentative (100) après une temporisation (149) en cas de réponse négative ; sinon, la fonction retourne une erreur
(110) indiquant que le fichier reste acquis par un traitement en cours. Si le résultat du test (107) est positif, la fonction procède à une tâche (111) d'écriture de l'état d'indisponibilité du fichier dans un paramètre d'état de l'en-tête du fichier, puis une tâche (112) de calcul d'un identifiant d'acquisition du fichier, une tâche (113) d'écriture de cet identifiant dans un paramètre d'état de l'en-tête du fichier, et une tâche (114) de lecture du corps du fichier. La tâche (115) correspond à un traitement du corps du fichier pour extraire le contenu modifiable du fichier. Ce traitement s'effectue en fonction de paramètres d'état de l'en-tête du fichier. Il correspond par exemple à une décompression ou un déchiffrage du contenu modifiable du fichier. La dernière tâche (116) consiste à fermer et déverrouiller simultanément le fichier au niveau du système de fichier du système d'exploitation.
La fonction renvoie en sortie à son achèvement (151) la confirmation de l'acquisition du fichier de données, l'identifiant d'acquisition du fichier et le contenu modifiable du fichier.
Fonction d'acquisition d'un fichier de données nouveau
La figure 3 représente la succession de tâches nécessaires pour l'acquisition d'un fichier de données nouveau.
La fonction prend en entrée (250) le nom d'un fichier calculé à partir du nom d'usage comme exposé précédemment.
La première tâche (200) consiste à tenter la création, l'ouverture et le verrouillage simultanés d'un nouveau fichier au niveau du système de fichier du système d'exploitation, en demandant une création, une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur. La fonction procède ensuite à un test (201) pour vérifier la création, l'ouverture et le verrouillage du fichier : si le fichier n'est pas créé, ouvert et verrouillé, le résultat du test (201) est négatif et la fonction procède à un deuxième test (202) qui vérifie si le fichier existait lors de la tentative (200).
En cas de réponse positive, la fonction retourne une erreur (204) indiquant que le fichier existe déjà.
En cas de réponse négative, la fonction renvoie une erreur (203) indiquant une erreur système.
Si le résultat du test (201) est positif, la fonction procède à une tâche (205) de création et d'écriture de l'entête du fichier avec un corps du fichier vide, puis une tâche (206) d'écriture de l'état d'indisponibilité du fichier dans un paramètre d'état de l' en-tête du fichier, puis une tâche (207) de calcul d'un identifiant d'acquisition du fichier, une tâche (208) d'écriture de cet identifiant dans un paramètre d'état de l' en-tête du fichier. La dernière tâche (209) consiste à fermer et déverrouiller simultanément le fichier au niveau du système de fichier du système d'exploitation.
La fonction renvoie en sortie à son achèvement (251) la confirmation de l'acquisition du fichier de données et l'identifiant d'acquisition du fichier.
Fonction d'acquisition d'un fichier de données existant avec création du fichier s'il n'existe pas
La figure 4 représente la succession de tâches nécessaires pour l'acquisition d'un fichier de données existant avec création du fichier s'il n'existe pas.
La fonction prend en entrée (350) le nom d'un fichier calculé à partir du nom d'usage comme exposé précédemment. La première tâche (300) consiste à tenter l'ouverture et le verrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation, et à créer le fichier s'il n'existe pas, en demandant une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
La fonction procède ensuite à un test (301) pour vérifier l'ouverture et le verrouillage du fichier : si le fichier n'est pas ouvert et verrouillé, le résultat du test
(301) est négatif et la fonction procède à un deuxième test
(302) qui vérifie si le fichier existait lors de la tentative (300). En cas de réponse négative, la fonction renvoie une erreur système (303). En cas de réponse positive, un test (304) vérifie si le nombre de tentatives (300) dépasse une valeur seuil, ou si le délai temporel est dépassé, et engage une nouvelle tentative (300) après une temporisation (349) en cas de réponse négative ; sinon, la fonction retourne une erreur système (305).
Si le résultat du test (301) est positif, la fonction procède ensuite à un test (306) pour vérifier si le fichier a été lors de la tentative (300) : si le fichier n'a pas été créé, le résultat du test (306) est négatif et la fonction lit l'état de disponibilité du fichier dans un paramètre d'état de l'en-tête du fichier lors d'une tâche (307).
La fonction procède ensuite à un test (308) de disponibilité du fichier en fonction de la valeur du paramètre d'état. Si le résultat du test (308) est négatif, correspondant à un état d'indisponibilité, la fonction procède à une tâche (309) de fermeture et de déverrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation. La fonction réalise ensuite un test (310) qui vérifie si le nombre de tentatives (300) dépasse une valeur seuil, ou si le délai temporel est dépassé, et engage une nouvelle tentative (300) après une temporisation (349) en cas de réponse négative ; sinon, la fonction retourne une erreur (311) indiquant que le fichier reste acquis par un traitement en cours.
Si le résultat du test (308) est positif, la fonction procède à une tâche (312) d'écriture de l'état d'indisponibilité du fichier dans un paramètre d'état de l'en-tête du fichier, puis une tâche (313) de calcul d'un identifiant d'acquisition du fichier, une tâche (314) d'écriture de cet identifiant dans un paramètre d'état de l'en-tête du fichier, et une tâche (315) de lecture du corps du fichier. La tâche (316) correspond à un traitement du corps du fichier pour extraire le contenu modifiable du fichier. Ce traitement s'effectue en fonction de paramètres d'état de l'en-tête du fichier. Il correspond par exemple à une décompression ou un déchiffrage du contenu modifiable du fichier. La tâche (317) consiste à fermer et déverrouiller simultanément le fichier au niveau du système de fichier du système d'exploitation.
La fonction renvoie en sortie à son achèvement (351) la confirmation de l'acquisition du fichier de données, une notification indiquant que le fichier n'a pas été créé, l'identifiant d'acquisition du fichier et le contenu modifiable du fichier.
Si le résultat du test (306) est positif, la fonction procède à une tâche (318) de création et d'écriture de l'en- tête du fichier avec un corps du fichier vide, puis une tâche (319) d'écriture de l'état d'indisponibilité du fichier dans un paramètre d'état de l'en-tête du fichier, puis une tâche (320) de calcul d'un identifiant d'acquisition du fichier, une tâche (321) d'écriture de cet identifiant dans un paramètre d'état de l'en-tête du fichier. La dernière tâche (322) consiste à fermer et déverrouiller simultanément le fichier au niveau du système de fichier du système d'exploitation. La fonction renvoie en sortie à son achèvement (352) la confirmation de l'acquisition du fichier de données, une notification indiquant que le fichier a été créé et l'identifiant d'acquisition du fichier.
Fonction de libération d'un fichier de données acquis sans modification des données
La figure 5 représente la succession de tâches nécessaires pour la libération d'un fichier de données acquis sans modification des données.
La fonction prend en entrée (450) le nom d'un fichier calculé à partir du nom d'usage comme exposé précédemment et un identifiant d'acquisition renvoyé lors d'une acquisition précédente du fichier de données. La première tâche (400) consiste à tenter l'ouverture et le verrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation, en demandant une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
La fonction procède ensuite à un test (401) pour vérifier l'ouverture et le verrouillage du fichier : si le fichier n'est pas ouvert et verrouillé, le résultat du test (401) est négatif et la fonction procède à un deuxième test (402) qui vérifie si le fichier existait lors de la tentative (400). En cas de réponse négative, la fonction renvoie une erreur (403) indiquant que le fichier n'existe pas. En cas de réponse positive, un test (404) vérifie si le nombre de tentatives (400) dépasse une valeur seuil, ou si le délai temporel est dépassé, et engage une nouvelle tentative (400) après une temporisation (449) en cas de réponse négative ; sinon, la fonction retourne une erreur système (405) .
Si le résultat du test (401) est positif, la fonction lit l'état de disponibilité du fichier dans un paramètre d'état de l' en-tête du fichier lors d'une tâche (406). La fonction procède ensuite à un test (407) de disponibilité du fichier en fonction de la valeur du paramètre d'état.
Si le résultat du test (407) est positif, la fonction procède à une tâche (408) de fermeture et de déverrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation et renvoie une erreur (409) indiquant que le fichier n'est pas acquis.
Si le résultat du test (407) est négatif, correspondant à un état d'indisponibilité, la fonction lit l'identifiant d'acquisition dans l' en-tête du fichier lors d'une tâche (410) .
La fonction réalise ensuite un test (411) qui contrôle si cet identifiant est différent de l'identifiant soumis en entrée. En cas de réponse positive, la fonction procède à une tâche (412) de fermeture et de déverrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation et renvoie une erreur (413) indiquant que l'identifiant d'acquisition soumis en entrée n'est pas valide. En cas de réponse négative, la fonction procède à une tâche (414) d'effacement de l'identifiant d'acquisition dans le paramètre d'état de l' en-tête du fichier, puis une tâche (415) d'écriture de l'état de disponibilité dans l' en-tête du fichier. La dernière tâche (416) consiste à fermer et déverrouiller simultanément le fichier au niveau du système de fichier du système d'exploitation.
La fonction renvoie en sortie à son achèvement (451) la confirmation de la libération du fichier de données.
Fonction de libération d'un fichier de données acquis avec modification des données
La figure 6 représente la succession de tâches nécessaires pour la libération d'un fichier de données acquis avec modification des données.
La fonction prend en entrée (550) le nom d'un fichier calculé à partir du nom d'usage comme exposé précédemment, un identifiant d'acquisition renvoyé lors d'une acquisition précédente du fichier de données et le contenu modifiable du fichier.
La première tâche (500) consiste à tenter l'ouverture et le verrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation, en demandant une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
La fonction procède ensuite à un test (501) pour vérifier l'ouverture et le verrouillage du fichier : si le fichier n'est pas ouvert et verrouillé, le résultat du test
(501) est négatif et la fonction procède à un deuxième test
(502) qui vérifie si le fichier existait lors de la tentative (500). En cas de réponse négative, la fonction renvoie une erreur (503) indiquant que le fichier n'existe pas .
En cas de réponse positive, un test (504) vérifie si le nombre de tentatives (500) dépasse une valeur seuil, ou si le délai temporel est dépassé, et engage une nouvelle tentative (500) après une temporisation (549) en cas de réponse négative ; sinon, la fonction retourne une erreur système (505) .
Si le résultat du test (501) est positif, la fonction lit l'état de disponibilité du fichier dans un paramètre d'état de l'en-tête du fichier lors d'une tâche (506).
La fonction procède ensuite à un test (507) de disponibilité du fichier en fonction de la valeur du paramètre d'état.
Si le résultat du test (507) est positif, la fonction procède à une tâche (508) de fermeture et de déverrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation et renvoie une erreur (509) indiquant que le fichier n'est pas acquis.
Si le résultat du test (507) est négatif, correspondant à un état d'indisponibilité, la fonction lit l'identifiant d'acquisition dans l'en-tête du fichier lors d'une tâche (510) .
La fonction réalise ensuite un test (511) qui contrôle si cet identifiant est différent de l'identifiant soumis en entrée. En cas de réponse positive, la fonction procède à une tâche (512) de fermeture et de déverrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation et renvoie une erreur (513) indiquant que l'identifiant d'acquisition soumis en entrée n'est pas valide.
En cas de réponse négative, la fonction procède à une tâche (514) d'effacement de l'identifiant d'acquisition dans le paramètre d'état de l'en-tête du fichier, puis une tâche (515) d'écriture de l'état de disponibilité dans l'en-tête du fichier, puis une tâche (516) correspondant à un traitement du corps du fichier pour y insérer le contenu modifiable du fichier. Ce traitement s'effectue en fonction de paramètres d'état de l'en-tête du fichier et correspond par exemple à une compression ou un chiffrage du contenu modifiable du fichier. La fonction procède ensuite à une tâche (517) d'écriture du corps du fichier et la dernière tâche (518) consiste à fermer et déverrouiller simultanément le fichier au niveau du système de fichier du système d'exploitation.
La fonction renvoie en sortie à son achèvement (551) la confirmation de la libération du fichier de données et de la modification du contenu du fichier.
Fonction de libération d'un fichier de données acquis avec effacement du fichier
La figure 7 représente la succession de tâches nécessaires pour la libération d'un fichier de données acquis avec effacement du fichier.
La fonction prend en entrée (650) le nom d'un fichier calculé à partir du nom d'usage comme exposé précédemment et un identifiant d'acquisition renvoyé lors d'une acquisition précédente du fichier de données. La première tâche (600) consiste à tenter l'ouverture et le verrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation, en demandant une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
La fonction procède ensuite à un test (601) pour vérifier l'ouverture et le verrouillage du fichier : si le fichier n'est pas ouvert et verrouillé, le résultat du test (601) est négatif et la fonction procède à un deuxième test (602) qui vérifie si le fichier existait lors de la tentative (600). En cas de réponse négative, la fonction renvoie une erreur (603) indiquant que le fichier n'existe pas. En cas de réponse positive, un test (604) vérifie si le nombre de tentatives (600) dépasse une valeur seuil, ou si le délai temporel est dépassé, et engage une nouvelle tentative (600) après une temporisation (649) en cas de réponse négative ; sinon, la fonction retourne une erreur système (605) .
Si le résultat du test (601) est positif, la fonction lit l'état de disponibilité du fichier dans un paramètre d'état de l'en-tête du fichier lors d'une tâche (606). La fonction procède ensuite à un test (607) de disponibilité du fichier en fonction de la valeur du paramètre d'état.
Si le résultat du test (607) est positif, la fonction procède à une tâche (608) de fermeture et de déverrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation et renvoie une erreur (609) indiquant que le fichier n'est pas acquis.
Si le résultat du test (607) est négatif, correspondant à un état d'indisponibilité, la fonction lit l'identifiant d'acquisition dans l'en-tête du fichier lors d'une tâche (610) .
La fonction réalise ensuite un test (611) qui contrôle si cet identifiant est différent de l'identifiant soumis en entrée. En cas de réponse positive, la fonction procède à une tâche (612) de fermeture et de déverrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation et renvoie une erreur (613) indiquant que l'identifiant d'acquisition soumis en entrée n'est pas valide. En cas de réponse négative, la fonction procède à une tâche (614) d'effacement de l'identifiant d'acquisition dans le paramètre d'état de l'en-tête du fichier, puis une tâche (615) d'écriture de l'état de disponibilité dans l'en-tête du fichier. La dernière tâche (616) consiste à fermer, déverrouiller et effacer simultanément le fichier au niveau du système de fichier du système d'exploitation.
La fonction renvoie en sortie à son achèvement (651) la confirmation de la libération du fichier de données et de son effacement.
Fonction de lecture simple d'un fichier de données existant sans acquisition du fichier
La figure 8 représente la succession de tâches nécessaires pour la lecture simple d'un fichier de données existant sans acquisition du fichier.
La fonction prend en entrée (750) le nom d'un fichier calculé à partir du nom d'usage comme exposé précédemment. La première tâche (700) consiste à tenter l'ouverture et le verrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation, en demandant une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
La fonction procède ensuite à un test (701) pour vérifier l'ouverture et le verrouillage du fichier : si le fichier n'est pas ouvert et verrouillé, le résultat du test (701) est négatif et la fonction procède à un deuxième test (702) qui vérifie si le fichier existait lors de la tentative (700). En cas de réponse négative, la fonction renvoie une erreur (703) indiquant que le fichier n'existe pas .
En cas de réponse positive, un test (704) vérifie si le nombre de tentatives (700) dépasse une valeur seuil, ou si le délai temporel est dépassé, et engage une nouvelle tentative (700) après une temporisation (749) en cas de réponse négative ; sinon, la fonction retourne une erreur système (705) . Si le résultat du test (701) est positif, la fonction lit l'état de disponibilité du fichier dans un paramètre d'état de l'en-tête du fichier lors d'une tâche (706).
La fonction procède ensuite à un test (707) de disponibilité du fichier en fonction de la valeur du paramètre d'état.
Si le résultat du test (707) est négatif, correspondant à un état d'indisponibilité, la fonction procède à une tâche (708) de fermeture et de déverrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation.
La fonction réalise ensuite un test (709) qui vérifie si le nombre de tentatives (700) dépasse une valeur seuil, ou si le délai temporel est dépassé, et engage une nouvelle tentative (700) après une temporisation (749) en cas de réponse négative ; sinon, la fonction retourne une erreur (710) indiquant que le fichier reste acquis par un traitement en cours .
Si le résultat du test (707) est positif, la fonction procède à une tâche (711) de lecture du corps du fichier, puis une tâche (712) de traitement du corps du fichier pour extraire le contenu modifiable du fichier. Ce traitement s'effectue en fonction de paramètres d'état de l' en-tête du fichier. Il correspond par exemple à une décompression ou un déchiffrage du contenu modifiable du fichier. La dernière tâche (713) consiste à fermer et déverrouiller simultanément le fichier au niveau du système de fichier du système d 'exploitation.
La fonction renvoie en sortie à son achèvement (751) la confirmation de la lecture simple du fichier de données et le contenu modifiable du fichier.
D'autres fonctions permettent de faciliter l'administration de l'arborescence, notamment : la lecture des paramètres d'état de l'en-tête d'un fichier de données, incluant l'état de disponibilité du fichier, la libération forcée d'un fichier de données qui n'a pas été libéré par un traitement, le listage des fichiers de données contenus dans l'arborescence par sous-ensembles de l'arborescence.
Mode client-serveur
La figure 9 concerne un cas d'application particulier et préféré. Elle représente la succession de tâches nécessaires pour l'utilisation du système de gestion de fichiers conforme à l'invention à travers un réseau, correspondant à un mode client-serveur.
Dans ce cas, le système de gestion de fichiers est installé sur un ordinateur serveur (800) qui comporte un logiciel serveur (801). L'ordinateur serveur est accessible par une pluralité d'ordinateurs clients (802 à 804) qui comportent chacun un logiciel client (805 à 807). Les échanges entre les logiciels clients et le logiciel serveur utilisent un protocole réseau de transport de type connu, par exemple HTTP ou de préférence un protocole sécurisé de type HTTPS. L'invention met dans ce cas en œuvre un protocole applicatif (808) permettant d'appeler les fonctions du système de gestion de fichiers conforme à l'invention par des commandes de type « acquisition de fichier » ou « libération de fichier » . Les fichiers sont répartis au niveau de l'ordinateur serveur en plusieurs sous ensembles (809 à 811), chaque sous-ensemble correspondant à une arborescence conforme à l'invention, appelée « table ». Le nom d'usage du fichier de données est désigné dans le protocole par « clé » . La première tâche (812) est exécutée sur l'un des ordinateurs clients par le logiciel client. Elle consiste à appeler une fonction d'acquisition, de libération ou de lecture simple portant sur une table et une clé. La deuxième tâche (813) est exécutée par le logiciel serveur sur l'ordinateur serveur. Elle consiste à exécuter la fonction demandée par le logiciel client.
La troisième tâche (814) est exécutée par le logiciel serveur sur l'ordinateur serveur. Elle consiste à renvoyer au logiciel client le résultat de la fonction demandée.
Optionnellement, le système comporte plusieurs serveurs, permettant de répartir la charge et le volume de stockage des données. Dans ce cas, le logiciel client (805 à
807) comporte des règles de sélection du serveur en fonction des tables et des clés.
Le logiciel serveur (801) peut également comporter des fonctionnalités de journalisation des opérations exécutées pour permettre la reconstruction incrémentale des arborescences de l'ordinateur serveur sur un serveur de secours sans effectuer une recopie complète des arborescences sur le serveur de secours .

Claims

REVENDICATIONS
1 - Procédé de gestion de fichiers, comportant une première étape d'organisation de la base de fichiers de données consistant à créer une arborescence de répertoires à M niveaux de N répertoires chacun, avec M étant un nombre entier supérieur à 1, et des étapes d'enregistrement de fichiers de données consistant à : appliquer une fonction de hachage sur l'identifiant d'un fichier de données F1 à enregistrer, déterminer le chemin du répertoire Rdi de destination dans l'arborescence à plusieurs niveaux, en fonction du résultat de l'étape précédente, enregistrer le fichier de données dans ledit répertoire Rdi déterminé par ladite fonction de hachage, à un emplacement fonction de l ' identifiant du fichier de données, et des étapes de lecture de fichiers de données consistant à : - appliquer la même fonction de hachage sur l'identifiant d'un fichier de données Fj à lire, déterminer le chemin du répertoire Rcj cible dans l'arborescence en fonction du résultat de l'étape précédente, - lire le fichier de données dans ledit répertoire Rcj déterminé par ladite fonction de hachage, à un emplacement fonction de l'identifiant du fichier de données.
2 - Procédé de gestion de fichiers selon la revendication précédente, caractérisé en ce que les fichiers de données sont répartis sur Q unités de stockage, chaque unité de stockage correspondant à P niveaux de répertoires de N répertoires. 3 - Procédé de gestion de fichiers selon l'une quelconque des revendications précédentes, caractérisé en ce que N est égal à 16, et en ce que la fonction de hachage est la fonction SHAl.
4 - Procédé de gestion de fichiers selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque fichier de données comporte un en-tête et un corps, le corps comprenant le contenu modifiable du fichier, le corps étant précédé par un en-tête comportant des paramètres d'état du fichier dans le système de gestion de fichiers, le procédé comportant une étape préalable d'acquisition d'un fichier cible par un traitement pour une série d'opérations, l'acquisition provoquant un changement d'état d'un au moins des paramètres de l' en-tête, ce changement d'état empêchant l'acquisition par un autre traitement jusqu'à sa libération.
5 - Procédé de gestion de fichiers selon l'une quelconque des revendications précédentes, caractérisé en ce que les opérations d'acquisition, de lecture et de libération sont commandées par un logiciel client, et les étapes correspondantes sont exécutées par un logiciel serveur.
6 - Procédé de gestion de fichiers selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape d'acquisition d'un fichier de données existant prenant en entrée (150) le nom d'un fichier calculé à partir du nom d'usage, ladite étape comprenant une première tâche (100) consistant à tenter l'ouverture et le verrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation, en demandant une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
7 - Procédé de gestion de fichiers selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape d'acquisition d'un fichier de données nouveau prenant en entrée (250) le nom d'un fichier calculé à partir du nom d'usage, la première tâche (200) consistant à tenter la création, l'ouverture et le verrouillage simultanés d'un nouveau fichier au niveau du système de fichier du système d'exploitation, en demandant une création, une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
8 - Procédé de gestion de fichiers selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape d'acquisition d'un fichier de données existant avec création du fichier s'il n'existe pas, la fonction prenant en entrée (350) le nom d'un fichier calculé à partir du nom d'usage, la première tâche (300) consistant à tenter l'ouverture et le verrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation, et à créer le fichier s'il n'existe pas , en demandant une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
9 - Procédé de gestion de fichiers selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape de libération d'un fichier de données acquis sans modification des données, la fonction prenant en entrée (450) le nom d'un fichier calculé à partir du nom d'usage comme exposé précédemment et un identifiant d'acquisition renvoyé lors d'une acquisition précédente du fichier de données, la première tâche (400) consistant à tenter l'ouverture et le verrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation, en demandant une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
10 - Procédé de gestion de fichiers selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape de libération d'un fichier de données acquis avec modification des données, la fonction prenant en entrée (550) le nom d'un fichier calculé à partir du nom d'usage comme exposé précédemment, un identifiant d'acquisition renvoyé lors d'une acquisition précédente du fichier de données et le contenu modifiable du fichier, la première tâche (500) consistant à tenter l'ouverture et le verrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation, en demandant une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
11 - Procédé de gestion de fichiers selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape de libération d'un fichier de données acquis avec effacement du fichier, la fonction prenant en entrée (650) le nom d'un fichier calculé à partir du nom d'usage comme exposé précédemment et un identifiant d'acquisition renvoyé lors d'une acquisition précédente du fichier de données, la première tâche (600) consistant à tenter l'ouverture et le verrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation, en demandant une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
12 - Procédé de gestion de fichiers selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape de lecture simple d'un fichier de données existant sans acquisition du fichier, la fonction prenant en entrée (750) le nom d'un fichier calculé à partir du nom d'usage comme exposé précédemment, la première tâche (700) consistant à tenter l'ouverture et le verrouillage simultanés du fichier au niveau du système de fichier du système d'exploitation, en demandant une ouverture et un verrouillage du fichier empêchant jusqu'à sa fermeture et son déverrouillage l'ouverture et le verrouillage de ce fichier par un traitement postérieur.
PCT/FR2008/000177 2007-02-13 2008-02-12 Procede de gestion de fichiers WO2008113921A2 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
KR1020137029338A KR101365861B1 (ko) 2007-02-13 2008-02-12 파일 관리 방법
CA002678186A CA2678186A1 (fr) 2007-02-13 2008-02-12 Procede de gestion de fichiers
US12/526,724 US8504541B2 (en) 2007-02-13 2008-02-12 File management method
JP2009548717A JP5123318B2 (ja) 2007-02-13 2008-02-12 ファイル管理方法
EP08761876A EP2130147A2 (fr) 2007-02-13 2008-02-12 Procede de gestion de fichiers
IL200252A IL200252A0 (en) 2007-02-13 2009-08-05 File management method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0753222 2007-02-13
FR0753222A FR2912520B1 (fr) 2007-02-13 2007-02-13 Procede de gestion de fichiers.

Publications (2)

Publication Number Publication Date
WO2008113921A2 true WO2008113921A2 (fr) 2008-09-25
WO2008113921A3 WO2008113921A3 (fr) 2009-09-24

Family

ID=38740236

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2008/000177 WO2008113921A2 (fr) 2007-02-13 2008-02-12 Procede de gestion de fichiers

Country Status (9)

Country Link
US (1) US8504541B2 (fr)
EP (1) EP2130147A2 (fr)
JP (1) JP5123318B2 (fr)
KR (2) KR101471055B1 (fr)
CN (1) CN101669118A (fr)
CA (1) CA2678186A1 (fr)
FR (1) FR2912520B1 (fr)
IL (1) IL200252A0 (fr)
WO (1) WO2008113921A2 (fr)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102012896B (zh) * 2010-12-29 2012-11-21 深圳市五巨科技有限公司 一种实现文件内容批量修改的方法和装置
US9934229B2 (en) * 2011-10-23 2018-04-03 Microsoft Technology Licensing, Llc Telemetry file hash and conflict detection
CN102446221A (zh) * 2011-12-22 2012-05-09 南京联创科技集团股份有限公司 Bs结构软件中的动态树型结构目录检索方法
US9323771B2 (en) * 2013-04-24 2016-04-26 Dell Products, Lp Efficient rename in a lock-coupled traversal of B+tree
CN105765559B (zh) 2013-09-09 2019-03-05 尤奈特戴克斯公司 交互式案件管理系统
CN105743721B (zh) * 2014-12-09 2019-02-15 博雅网络游戏开发（深圳）有限公司 数据上报方法、对上报数据进行处理的方法和装置
US10108624B1 (en) * 2015-02-04 2018-10-23 Amazon Technologies, Inc. Concurrent directory move operations using ranking rules
CN107506395A (zh) * 2017-07-31 2017-12-22 合肥龙图腾信息技术有限公司 一种对打开状态文件重命名的方法及系统
CN108197302A (zh) * 2018-01-29 2018-06-22 维沃移动通信有限公司 一种文件夹创建方法及移动终端
BE1027121B1 (fr) * 2019-03-15 2020-10-14 Christophe Dutordoir Système de vote électronique sur internet
CN111159109A (zh) * 2019-11-26 2020-05-15 陶壮壮 一种磁盘空间占用文件的检测方法及系统
CN111054082B (zh) * 2019-11-29 2023-10-13 珠海金山数字网络科技有限公司 Unity资源数据集编码的方法
EP3776250B1 (fr) * 2019-12-05 2022-08-24 Alipay (Hangzhou) Information Technology Co., Ltd. Réalisation d'itérations de carte dans un système à chaîne de blocs

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0463874A2 (fr) * 1990-06-29 1992-01-02 Digital Equipment Corporation Dispositif d'antémémoire pour système de fichiers dans un système de traitement de données numériques
US5692178A (en) * 1992-08-20 1997-11-25 Borland International, Inc. System and methods for improved file management in a multi-user environment
US5742817A (en) * 1995-12-08 1998-04-21 Emc Corporation Method and apparatus for file server addressing
US6470345B1 (en) * 2000-01-04 2002-10-22 International Business Machines Corporation Replacement of substrings in file/directory pathnames with numeric tokens
US6625591B1 (en) * 2000-09-29 2003-09-23 Emc Corporation Very efficient in-memory representation of large file system directories
EP1452981A2 (fr) * 2003-02-28 2004-09-01 Microsoft Corporation Méthode pour retarder le vérouillage de fichiers à l'édition
US20040236761A1 (en) * 2003-05-23 2004-11-25 Hans-Joachim Both File system storage

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5864852A (en) * 1996-04-26 1999-01-26 Netscape Communications Corporation Proxy server caching mechanism that provides a file directory structure and a mapping mechanism within the file directory structure
US5893086A (en) * 1997-07-11 1999-04-06 International Business Machines Corporation Parallel file system and method with extensible hashing
JP2000357115A (ja) * 1999-06-15 2000-12-26 Nec Corp ファイル検索装置及びファイル検索方法
US6687716B1 (en) * 2000-09-13 2004-02-03 Radiant Data Corporation File consistency protocols and methods for carrying out the protocols
US6965893B1 (en) * 2000-12-20 2005-11-15 Oracle International Corporation Techniques for granting shared locks more efficiently
US7062490B2 (en) * 2001-03-26 2006-06-13 Microsoft Corporation Serverless distributed file system
US6912645B2 (en) * 2001-07-19 2005-06-28 Lucent Technologies Inc. Method and apparatus for archival data storage
JP4154893B2 (ja) * 2002-01-23 2008-09-24 株式会社日立製作所 ネットワークストレージ仮想化方法
JP2006185232A (ja) * 2004-12-28 2006-07-13 Hitachi Ltd 複数のプログラムの実行方法、プログラム変換方法及びこれを用いたコンパイラプログラム
US7434057B2 (en) 2005-01-27 2008-10-07 Hitachi, Ltd. System and method for watermarking in accessed data in a storage system

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0463874A2 (fr) * 1990-06-29 1992-01-02 Digital Equipment Corporation Dispositif d'antémémoire pour système de fichiers dans un système de traitement de données numériques
US5692178A (en) * 1992-08-20 1997-11-25 Borland International, Inc. System and methods for improved file management in a multi-user environment
US5742817A (en) * 1995-12-08 1998-04-21 Emc Corporation Method and apparatus for file server addressing
US6470345B1 (en) * 2000-01-04 2002-10-22 International Business Machines Corporation Replacement of substrings in file/directory pathnames with numeric tokens
US6625591B1 (en) * 2000-09-29 2003-09-23 Emc Corporation Very efficient in-memory representation of large file system directories
EP1452981A2 (fr) * 2003-02-28 2004-09-01 Microsoft Corporation Méthode pour retarder le vérouillage de fichiers à l'édition
US20040236761A1 (en) * 2003-05-23 2004-11-25 Hans-Joachim Both File system storage

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BRESSOUD T C ET AL: "OPEN CAS: A FLEXIBLE ARCHITECTURE FOR CONTENT ADDRESSABLE STORAGE" PROCEEDINGS OF THE ISCA INTERNATIONAL CONFERENCE, PARALLEL AND DISTRIBUTED COMPUTING SYSTEMS, XX, XX, 15 septembre 2004 (2004-09-15), pages 580-587, XP009068171 *
PAXTON W H: "A Client-Based Transaction System to Maintain Data Integrity" PROCEEDINGS OF THE SEVENTH ACM SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES, 1979, pages 18-23, XP040160130 ACM, 2 PENN PLAZA, SUITE 701 - NEW YORK USA ISBN: 0-89791-009-5 *
SVOBODOVA L: "File Servers for Nwtwork-Based Distribured Systems" COMPUTING SURVEYS, vol. 16, no. 4, décembre 1984 (1984-12), pages 353-398, XP040000208 ACM, 2 PENN PLAZA, SUITE 701 - NEW YORK USA *

Also Published As

Publication number Publication date
US20100106696A1 (en) 2010-04-29
WO2008113921A3 (fr) 2009-09-24
FR2912520B1 (fr) 2009-05-15
CA2678186A1 (fr) 2008-09-25
EP2130147A2 (fr) 2009-12-09
CN101669118A (zh) 2010-03-10
JP2010518501A (ja) 2010-05-27
KR101365861B1 (ko) 2014-02-20
KR20090116743A (ko) 2009-11-11
JP5123318B2 (ja) 2013-01-23
FR2912520A1 (fr) 2008-08-15
US8504541B2 (en) 2013-08-06
KR20130130876A (ko) 2013-12-02
IL200252A0 (en) 2010-04-29
KR101471055B1 (ko) 2014-12-09

Similar Documents

Publication Publication Date Title
EP2130147A2 (fr) Procede de gestion de fichiers
US8489549B2 (en) Method and system for resolving conflicts between revisions to a distributed virtual file system
US20150019599A1 (en) Object file system
WO2003071430A1 (fr) Méthode de stockage de blocs de données dans une mémoire
EP1977365B1 (fr) Procede de gestion de documents electroniques
EP1866770B1 (fr) Méthode et système pour maintenir la cohérence d'une mémoire cache utilisée par de multiples processus indépendants
CN106227830A (zh) 存储和读取文件的方法和装置
EP3623979B1 (fr) Methode de stockage securise dans un reseau d'une image de conteneur dans un registre de conteneurs
FR3025340A1 (fr) Nuage de donnees
WO2015166052A1 (fr) Acquisition de données
WO2018096125A1 (fr) Procédé d'insertion de données à la volée dans une base de données tatouées et dispositif associé
FR3084496A1 (fr) Procede et dispositif de generation d'instructions destinees a un dispositif pour realiser une mise a jour sur place d'un fichier de donnees
FR3073061B1 (fr) Procede de communication entre processus, programme d’ordinateur et installation informatique correspondants
EP2353076A1 (fr) Procede et systeme de stockage virtualise d'un ensemble de donnees numeriques
FR3012900A1 (fr) Procede de protection de metadonnees
WO2021044094A1 (fr) Procede de gestion d'un groupe de donnees dans un systeme informatique
FR2997595A1 (fr) Procede d'indexation des contenus d'un dispositif de stockage de contenus numeriques connecte a un boitier d'acces a internet
EP2212791A2 (fr) Système informatique amélioré comprenant plusieurs noeuds en réseau
FR2925722A1 (fr) Reseau informatique dote d'un archivage automatique de fichiers

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200880010343.9

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08761876

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2008761876

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 200252

Country of ref document: IL

Ref document number: 5079/DELNP/2009

Country of ref document: IN

ENP Entry into the national phase

Ref document number: 2009548717

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2678186

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 1020097016865

Country of ref document: KR

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 12526724

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 1020137029338

Country of ref document: KR