WO2000079384A2

WO2000079384A2 - Method and apparatus to rename open files

Info

Publication number: WO2000079384A2
Application number: PCT/US2000/040197
Authority: WO
Inventors: William E. Sobel; Mark Kennedy
Original assignee: Symantec Corporation
Priority date: 1999-06-18
Filing date: 2000-06-15
Publication date: 2000-12-28
Also published as: EP1194841A2; CA2375517A1; WO2000079384A3

Abstract

A file stored on a storage media can be updated even while it is being accessed by an application and without requiring a reboot. In one embodiment of the invention a file stored on a storage media, having a file name listed in a directory, is updated by placing an updated version of the file on the storage media. A listing for the updated version of the file is added to the directory under a temporary name. The original file name listed in the directory is changed to a different name, and the temporary name is changed to the former name of the original file.

Description

METHOD OF APPARATUS TO RENAME OPEN FILES

BACKGROUND OF THE INVENTION

1. Field of Invention

The present invention generally relates to upgrading or otherwise altering or updating files stored on a computer system. More particularly, the present invention is directed to the updating of a file on a computer system that is already being accessed by an application.

BACKGROUND Computer systems, for instance personal computers (PCs), perform various tasks by running applications, i.e., computer programs. Once running, applications often need to access particular files stored on the computer system. Such files may be data files, program files, or other types of files. Once a file has been accessed by a particular application, no operations may be performed on the file itself. In other words, when the file is in use, the file may not be renamed, deleted, or otherwise updated. Typically when the need arises to upgrade, install, deinstall, change, or otherwise update a file, a new updated version of the file with a temporary name is first created. For instance, assume an original file is named "FILE, " and a new updated version of the file is placed on the system with the temporary name "NEWFILE. " After NEWFILE has been created, then the system is rebooted. At the time of reboot, the original file, FLLE, is deleted and the new file is renamed to have the name of the deleted file, i.e., NEWFILE is renamed FLLE. Hence, no application has access to a file at the time that it is being updated. It is not always desirable or even possible to reboot a machine at the time of updating a file. For instance, many computer systems perform critical functions that need to be running uninterrupted at all times. But even if a network process could monitor such a computer system to determine when it is idle, and then perform updates automatically, including a computer system reboot, such an unattended reboot could be disastrous, and any number of things could go wrong, including failure of the computer system to resume operation. In other words, a reboot generally demands a human presence, often simply for minor updates to a single application in the computer system.

SUMMARY In order to avoid the drawbacks of conventional systems described above, a method and system in accordance with the invention is disclosed. Specifically, a method and system in accordance with the invention can update a file even while the file is being accessed by an application and will not require a reboot for subsequent accesses by other applications.

In one embodiment of the invention a file is stored on a storage media and has a file name listed in a directory. An updated version of that file is subsequently provided on the storage media. In this embodiment, a listing for the updated file is added to the directory under a temporary name. The original file name listed in the directory is changed to a different name, and the temporary name is changed to the former name of the original file.

In this manner, because applications only access a directory structure once for each file, applications accessing the file prior to the update will continue to access the older version of the file. Applications requesting access to a file subsequent to the update will access the updated version of the file. No reboot is necessary and applications continue to operate undisturbed. BRIEF DESCRIPTION OF THE DRAWINGS The present invention is described with respect to particular exemplary embodiments thereof and reference is accordingly made to the drawings in which: Figure 1 is a generalized block diagram of a computer system;

Figure 2 illustrates, in generalized block diagram format, the accessing of files by an application;

Figure 2a illustrates a directory structure as modified conventionally following a reboot; Figure 3 is a flow diagram representing the steps taken to access a file by an application;

Figure 4 is a flow diagram illustrating the steps conventionally taken in updating a particular file;

Figure 5 illustrates, in generalized block diagram format, the end result of a system and method in accordance with the invention;

Figures 5A-5C illustrates the changes made to a directory structure in accordance with the invention; and

Figure 6 is a flow diagram illustrating the steps taken in accordance with the invention.

DETAILED DESCRIPTION A method and system in accordance with the invention allows a file to be upgraded, altered, or otherwise updated without requiring the conventional reboot and can be done even if that file is being accessed by an application. Details of an embodiment of the invention are set forth below.

Fig. 1 illustrates a computer system 100 that is used in one embodiment of the invention. The computer system 100 includes a central processing unit (CPU) 102, a memory unit 104, such as RAM, and non- volatile memory devices such as a bulk storage device 106, e.g. , a hard drive, a solid state device 108, e.g. , ROM, and a portable media drive 110, e.g. , a floppy disk drive or a CD-ROM drive. The portable media may comprise, for example, a CD, a floppy disk, or an optical disk. The applications and files described herein may reside in whole or in part in any of the storage units 104-114 or a wide variety of other computer- readable storage media. Hence, storage umts 104-114 are generically referred to herein as "storage media."

In one embodiment, the CPU 102 communicates with the bulk storage device 106, the solid state media 108, the portable media drive 110, via a host bus 116. However, in another embodiment of the invention, the CPU 102, communicates with peripheral devices such as devices 106-110 through one or more of a variety of input/output interface circuitry, including bus bridge circuits, that enable communication between the host bus 116 and a variety of standardized peripheral buses. Thus, it is to be understood that Fig. 1 is illustrative only and is not intended to limit the invention to the illustrated structure.

The computer system 100 is generally controlled by an operating system, for instance Windows 95, Windows 98, or other Windows version (generally referred to herein as Windows 9x) produced by Microsoft

Corporation of Redmond, Washington. The operating system maintains a file system structure to enable location of files stored on the various storage devices 104-110. This file system structure generally includes a directory (DIR) structure and a file allocation table (FAT). Only the directory structure is important for purposes of the present invention. Therefore, the FAT will not be described further.

Storage media, particularly floppy disks and hard disk drives, are divided into clusters. Although clusters are often comprised of one or more sectors, the minimum storage unit is often considered to be a cluster. Each file, whether it be an application, a data file, or other file type, will be stored on one or more storage media, and will be located in one or more clusters. Fig. 2 illustrates storage media 210 having a number of clusters 212. Although only twenty clusters are illustrated, it is to be understood by those of skill in the art that any given storage media may have thousands of such clusters.

Referring to Fig. 2, to keep track of files, an operating system 202 maintains a directory structure (DIR) 204. The directory structure includes a list of files, for instance file A, file B, file C, and file D. Correlated with each file name is a starting cluster, identifying where in the storage media 210 the file begins. As shown in the example of Fig. 2, file A begins at cluster 1 , while file B begins at cluster 5. Intervening clusters, e.g., clusters 2-4, may include parts of the same file, e.g. , file A, or may include parts of other files as will be understood by those skilled in the art.

Currently in a Windows 9x operating system, when an application 216 requires access to a file, it refers to the directory structure 204 to find the starting cluster of the file. Referring to Figs. 2 and 3, if application 216 requires access to file B, it looks up file B in directory 204 to find file B's starting cluster, cluster 5, step 302. In step 304, application 216 then stores or "caches" the starting cluster for file B, for instance in register 218. Once application 216 has obtained the starting cluster for file B, application 216 will access file B directly in the storage media, step 306, and has no need to look up file B again in directory 204 as long as application 216 is running. Any other application 220 also needing access to file B will follow the same process.

In Windows 9x systems, in order to update a file, including upgrading, mstalling, deinstalling, or otherwise altering a file, the following steps are taken. Referring to Figs. 2 and 4, a new updated version of a file, e.g. , new file B, is added to the storage media 210, step 402. As shown in Fig. 2, new file B is added at cluster 18 in storage media 210. In step 404, an entry is made in an operating system file, e.g. , wininit.ini 206. The entry instructs the operating system to modify the directory structure, replacing the entry for the old file, file B, with an entry for the new file B at reboot time. Wininit.ini is processed by another file, win.com, prior to booting into protective mode windows as is known in the art. At reboot, in accordance with the instructions placed in wininit.ini, the old file B is deleted and the directory is modified accordingly.

For instance, Fig. 2, illustrates the directory 204 and the storage media 210 after the new, updated file has been added to storage media 210 but before the system is rebooted. Fig. 2A illustrates the directory 204 after reboot. In Fig. 2A, the old file B has been deleted, but the new file B has been added, showing the starting cluster at cluster 18, and named "B. " After reboot, all files requiring access to file B, will look up file B in the directory 204 and obtain the starting cluster 18 and then access the updated file B, as shown by the dashed lines.

Thus, in accordance with the conventional schemes, files cannot be accessed and updated simultaneously in the current Windows 9x scheme. Nonetheless, in accordance with the invention, a system and method is disclosed that allows a file to be updated even while it is being accessed.

In accordance with the invention, an application will still access the directory and follow the steps described with reference to Figs. 2 and 3. In other words, application 216 will access directory structure 204 and retrieve a start cluster for file B, step 302. Upon retrieving the start cluster, e.g. , cluster 5, application 216 will store the starting cluster value for file B, and application 216 will access the file directly from storage media 210 without ever referring back to directory structure 204 again.

Now referring to Figs. 5 and 6, if it is desired to upgrade or otherwise change file B (generally referred to herein as "updating" file B), a new, updated version of a file B is added to the storage media 210. In step 602 the directory structure 204 is altered directly. The new version of file B is added to the directory under a temporary name, e.g. , TEMP B, with its starting cluster, e.g., cluster 18. In step 604, the old file is renamed in the directory, for instance to "OLDB. " In step 606, the new file is renamed in the directory, giving it the former name of the old file, e.g. , file "B. " Finally, in step 608, an entry is made in wininit.ini to remove the entry for the old file from the directory on the next reboot, whenever that occurs.

Figs. 5A-5C show the evolution of the directory structure. Fig. 5A shows the directory structure initially, before any file updates, showing original file B starting at cluster 5. In Fig. 5B, after the updated version of the file has been added to the storage media, the directory structure is altered to show that the new file has been added, entitled "TEMP B," indicating that the new file B has been temporarily named. And finally in Fig. 5C, the original file B is renamed "OLDB" while the new file B is renamed "B. " As will be understood by those of skill in the art, the file names provided herein are exemplary only.

Nonetheless, as will be known to those of skill in the art, when a modification is to be made directly to the data stored on a storage media, without the assistance of the operating system, a "lock" is requested for the storage media. Prior to the lock request, the operating system stores information about each file open from the storage media in an internal data structure that is somewhat like a cache, storing such information as the filename, the start cluster, cluster chains and other information that allows for ready access to the file. In Windows 9x, such a data structure is a System File Table (SFT), also sometimes referred to as an Open File Table (OFT). In response to a lock request, the operating system "forgets" the information it has stored in the SFT about all files currently open from the storage media except the filenames, since any modification to the storage media could affect the information. When the lock is released, the operating system looks up information correlating to the open files for the SFT, thereby "relearning" the information.

If left alone, however, when the lock is released after performing the steps described with respect to Figs. 5 and 6, the operating system will look up information for file "B", but will obtain information for the new updated file "B" rather than the old file B since the names have been changed, possibly causing a system crash. Therefore, in one embodiment of the invention at the time of performing steps associated with Figs. 5A-5C, the SFT structure (or other corresponding data structure) is also modified, renaming file "B" to

"OLD B" in the SFT. In this manner, when the operating system attempts to "relearn" information about the file, it will seek information about the file that was previously opened, e.g., OLD B.

As shown in Fig. 5, which shows the directory structure after an update in accordance with the invention has occurred, application 216 which has already stored the starting cluster of the old file B will continue to access the old file B as if no changes had occurred. All other applications subsequently seeking access to File B, e.g, application 220, will look up File B in the directory structure and be directed to the starting cluster for the new, updated version of file B, cluster 18. Like application 216, application 220 will store the starting cluster for the new, updated version of file B and access the new file B without again looking up file B in the directory structure 204. Hence, in accordance with the invention, the application that is already accessing a file is unaffected by the update process since it already has the information required to access the designated file. Yet, accesses by other applications subsequent to the update process will be directed to the new file. Therefore, a system and method in accordance with the invention allows for the upgrade, installation, deinstallation, or other updating of files without requiring any applications to be shut down and without requiring a reboot of the system.

It is to be understood by those of skill in the art, that the system and method in accordance with the invention may be implemented in hardware, software, or firmware. When implemented in software, an embodiment in accordance with the invention may form a stand-alone application program, for instance, a utility program shown in Fig. 5 at 222, or may be included as part of other applications, e.g., in a setup or installation routine. Therefore, an embodiment of the invention may be included on any of the storage media

104-114 illustrated in Fig. 1 or any other type of storage media.

It is to be further understood that although Windows 9x is used herein as an exemplary operating system, a method and system in accordance with the invention could be used with other operating systems. It should be understood that the particular embodiments described above are only illustrative of the principles of the present invention, and various modifications could be made by those skilled in the art without departing from the scope and spirit of the invention. Thus, the scope of the present invention is limited only by the claims that follow.

Claims

What Is Claimed Is:

1. In a computer system, a method for updating a file, comprising the steps of: accessing a file by an application; updating said file while said file is being accessed by said application without interfering with said application and without requiring a reboot.

2. The method of claim 1 , wherein: updating includes allowing two versions of said file to coexist simultaneously.

3. The method of claim 1, wherein: updating includes modifying a directory that lists said file.

4. The method of claim 3, wherein said file is stored in a storage media and has a file name, and wherein: accessing includes looking up said file name in said directory; updating further includes providing an updated version of said file in said storage media; and modifying includes changing said file name in said directory to a different name and adding said file name to said directory with a pointer to said updated version of said file.

5. In a computer system, a method for updating a file stored on a storage media, said file having a file name listed in a directory, comprising:

(a) providing an updated version of said file in said storage media;

(b) adding a listing for said updated version of said file to said directory under a temporary name; (c) changing said file name to a different file name;

(d) changing said temporary name to said file name.

6. The method of claim 5, wherein (a)-(d) occur after a step of accessing said file by an application, said step of accessing said file including looking up said file name in said directory.

7. The method of claim 6, wherein said file and said updated version of said file coexist simultaneously on said storage media, and further comprising: continuing to access said file by said application; accessing said updated version of said file by a second application, including looking up said file name in said directory.

8. A computer system, comprising: storage media means for storing files; update means for updating at least a first one of said files even while said first one of said files is being accessed by an application and without interfering with said application and without requiring a reboot.

9. The computer system of claim 8, further including: directory means for keeping track of said files; and wherein said update means includes: means for providing an updated version of said file in said storage media means; means for adding a listing for said updated version of said file to said directory means under a temporary name; means for changing said file name to a different file name; and means for changing said temporary name to said file name.

10. A computer system, comprising: an operating system; a directory maintained by said operating system; a storage media, including at least one file stored therein; a file update application, in communication with said storage media and said directory, designed to update said file without requiring a reboot of said computer system.

11. The computer system of claim 10, wherein said at least one file has a file name, and wherein said file update application includes: instructions for adding an updated version of said file to said directory under a temporary name; instructions for changing said file name to a different file name; instructions for changing said temporary name to said file name.

12. The computer system of claim 10, wherein said file update application is a stand-alone update utility.

13. The computer system of claim 10, wherein said file update application is part of a larger application.

14. A computer readable medium having a set of instructions stored therein, which when executed by a computer causes the computer to update a file stored in a storage media, said file having a file name listed in a directory, by performing the steps of:

(a) providing an updated version of said file in said storage media;

(d) changing said temporary name to said file name.

15. The computer readable medium of claim 14, wherein instructions for performing said steps (a)-(d) are executed after an application has accessed said file, including looking up said file name in said directory.