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

Definitions

• the invention concerns a scheme for automated file pruning and an automated file pruning facility for use in computer systems and networks.
• a typical computer system comprises a central processing unit, memory, peripheral devices such as data input/output devices and storage media such as floppy disks or hard disks.
• the devices communicate with each other via a computer operating system.
• Computer operating systems include several different operational modules.
• One such module might be a file manager.
• Client data stored on a storage medium is organized as a file system having an associated format, and the file manager is employed to maintain the available file systems and control access to them.
• the file manager provides a set of system calls in the form of Application Programmer Interfaces (APIs) to allow clients access to the file system and files, to carry out operations such as file creation, deletion, opening for read or write, and so on.
• APIs Application Programmer Interfaces
• the file system stores, organizes and describes client data.
• the client data is stored in files.
• the files are arranged in each file system in a particular format.
• Each file system maintains its organization and some sort of description information, herein referred to as metadata, in format specific structures. Examples of such formats are HFS, MS-DOS FAT, ProDOS, High Sierra, ISO 9660, NTFS, and so on.
• the term format encompasses both physical disk format and network server access protocols.
• the file manager To read and write data from and to the file system, the file manager must be able to recognize the format of the file system.
• FIG. 1 is an illustration of an exemplary embodiment of the present invention.
• element is herein used to describe an element of a database.
• elements are: files (e.g., computer or machine readable files), partial information to be added to an existing file, an image from an image repository, for example, a multimedia object (e.g., an avi or mpeg movie).
• databases are herein used to describe any collection, library, or repository of information, such as a file database, or an image repository. Examples of databases are a DOS or Windows file directory.
• a database system is the system which houses the database. A database system and/or a database can be distributed.
• An element content is herein referred to as data.
• An element might for example comprise client data, data generated by an application program, computer code for execution by a processor, and so forth.
• the elements are arranged in each database system in a particular format and each database system maintains its organization and some sort of description information, herein referred to as metadata, in format specific structures.
• the metadata may contain the following exemplary information: file attributes, file name, date of creation, date of last revision, users with access permission, file size, file type (e.g., Lotus WordPro), etc.
• the metadata can be kept in the same memory as the elements' data or they can be kept in a separate memory, e.g., a cache memory.
• the metadata are like a card catalog that is found in the library, with the library being analogous to the database system.
• a database system enables the user to store, manage, share and reuse information about the elements which are stored in it.
• the repository enables the user to store more than just the elements' data.
• the metadata stored in the database system may comprise information about the development of applications; including descriptions of data, programs and system objects. It may also include information about relationships among data, programs and system objects; as well as the semantics and use of the information.
• the basic idea of the present scheme is to provide an automated file pruning facility which automatically removes elements (e.g. files) no longer needed from a database system.
• elements e.g. files
• File Generation During file generation, e.g. when creating a file or adding a file to a database, a field is added to the file's metadata (e.g. to the file descriptor). This new field, which specifies the lifetime of the file, has to be initially set at the time a new file is generated or before the file is stored in the file database.
• File Representation or Marking When a file 21 is first created the user has to select a lifetime (step 12). This can be done by asking the user to accept a default file lifetime, to specify a specific file lifetime, or to declare the file as "permanent", as illustrated in box 16. Likewise, the user might also be prompted by the system to categorize the file 21 using a predefined categorization scheme (box 11). If the file 21 is categorized in a group of "legal documents”, the default lifetime used for all legal documents (e.g. 20 years from data of creation) is assigned to the respective file 21. If the user categorizes the file 21 into a directory with private documents, a shorter period might be assigned, just to give an example.
• the lifetime can be defined by a user or an application program. Information concerning record retention rules might be provided to the user prior to defining the lifetime of a particular file.
• File Disposal When the file lifetime limit is reached, the file 19 will be erased, as indicated on the right hand side of Figure 1. This could be done by code scanning file descriptions in search for files which have reached their end-of-life (step 13). This code be run automatically at a specified frequency. An optional feature could be employed that asks the user to approve the list of files to be erased.
• the metadata are examined from time-to-time to determine whether the lifetime of an element expired such that an element can be removed from said memory if its lifetime expired. Likewise, a user can be prompted if the lifetime of an element is about to expire or after it expired but before it is deleted by the system. In this case, the user has the option to chose whether the element is to be removed from said memory, or whether to change the element's lifetime.
• the normal class "file” can be extended (e.g., through the inheritance mechanism in object-oriented programming) to a new class.
• This new class can be called “limited lifetime” class for example.
• the "limited lifetime” class comprises all those files which the user would like to have automatically removed at a later date.
• the user would be asked to accept a default lifetime or to specify a particular file lifetime. Together, the current date and the lifetime specify akill time for the file at which time it can be deleted.
• the file is created, it is registered with the database or file manager as a "limited lifetime” type. The database or file manager will periodically scan its list of files with the type of "limited lifetime” and remove any whose kill time had expired.
• FIG. 1 shows a schematic representation of a file system 20 with several files. It furthermore shows a sequence of steps 15 for adding a new file 21, and a process for pruning (step 13) of the file system 20. According to the present embodiment, there are three steps that are carried out if a new file 21 is needed (step 14). A lifetime has to be selected (step 12), according to the present invention. Three options (box 11, box 16, and box 17) are offered for selection of the lifetime.
• each container has a preassigned lifetime.
• the user wants to create a new file 21 that contains legal information, or that belongs in the legal category, he selects the respective legal container during step 12.
• the container can be selected by clicking on it (if a graphical user interface is employed), by using hot keys, or the like. By doing so the legal container's preassigned lifetime is assigned to the new file 21.
• a different approach for selection of the lifetime is illustrated in box 16.
• the user may select a file, a file icon, or use an application program to create a new file 21.
• he is presented with a dialogue to accept a default lifetime, specify a specific file lifetime, or to declare this file as permanent. This can be done by using appropriate icons, hot keys, or other well known means.
• box 11 and 16 are well suited for systems which help the user to observe record retention rules.
• the approach of box 1 1 is particularly well suited because the user does not need to worry about record retention rules at all. He just needs to put his newly created files in the right category. The rest is done by the system.
• box 17 Another alternative is illustrated in box 17 where the system call to create a file 21 is extended to include the specification of the desired lifetime for the file 21. This can be done through the application programming interface (API).
• API application programming interface
• the actual file is created (step 10) and the lifetime is stored in the file's metadata. It is obvious that the sequence of steps can be changed. It is conceivable, for example, that a file 21 is created if needed by using an application software (e.g. a text processing software). When saving the newly created file to disk, or when adding it to the file system 20, the user may be asked to select a lifetime.
• an application software e.g. a text processing software
• the file system is automatically pruned. This pruning process is indicated by box 13. If during the pruning process a file 19 is discovered whose lifetime expired, then the respective file is discarded. As a optional safety net, the user might be prompted prior to this. Instead of prompting the user, all the files that are about to be deleted can be put in a waste basket. Here the files remain for a certain period of time. This gives the user an opportunity to intervene. If he does not remove the files from the waste basket, then the files are finally deleted.
• a system in accordance with the present invention can also offer a feature which allows the user to act upon an element (e.g. a file) that is stored in a database (e.g. a file system).
• an element e.g. a file
• a database e.g. a file system
• the metadata of the respective element is fetched and displayed. Then, the user can act upon the element.
• Typical actions are: accessing, retrieving, opening, displaying, moving, or copying the element.
• the user can also changing the element's lifetime or he can link the lifetime with the lifetime of another element.
• the linking can be done by a drag-and-drop operation where the element is moved into a container with a desired preassigned lifetime, for example.
• the present invention can be realized in hardware, software, or a combination of hardware and software. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited.
• a typical combination of hardware and software could be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.
• the present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which - when loaded in a computer system - is able to carry out these methods.
• the present invention can also be used in systems with parallel data sharing access to files residing on network attached shared disks.
• a special viewer can be used to review the lifetime of the files in a database.
• the viewer might offer a tool that organizes the files on a screen or within a window by their lifetime, for example.
• the viewer can be used to act upon the files and/or their lifetimes. Let us assume that one company decides to take legal action against another company. In such a situation all the documents that are of relevance are to be produced. It is important to avoid that these documents are deleted. All relevant documents can thus be displayed by the viewer and the user can act upon them. He might for example assign a new lifetime to each such document to ensure that the are kept for another five years.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Data Mining & Analysis (AREA)
• Databases & Information Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Priority Applications (2)

Applications Claiming Priority (2)

Publications (1)

Family

ID=8237899

Family Applications (1)

Country Status (5)

Cited By (51)

Citations (2)

• 1999
  • 1999-12-16 TW TW088122114A patent/TW460812B/zh not_active IP Right Cessation
• 2000
  • 2000-02-22 WO PCT/IB2000/000188 patent/WO2000058865A1/en active Application Filing
  • 2000-02-22 HU HU0200614A patent/HUP0200614A2/hu unknown
  • 2000-02-22 JP JP2000608289A patent/JP2002540530A/ja active Pending
  • 2000-02-22 AU AU25671/00A patent/AU2567100A/en not_active Abandoned

Patent Citations (2)

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events