Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-11-12
2002-05-07
Breene, John (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
Reexamination Certificate
active
06385623
ABSTRACT:
BACKGROUND
The disclosures herein relate generally to factory-installation of software and, more particularly, to a method of ensuring that scheduled file updates are applied with regard to previously existing versions and multiple instances of said updates.
This application relates to co-pending U.S. patent application Ser. No. 09/060,123, filed on Apr. 14, 1998, entitled LATE BINDING DYNAMIC SOFTWARE CONFIGURATION INFORMATION, naming Varnsi Ayyagari as an inventor. The co-pending application is incorporated herein by reference in its entirety, and is assigned to the assignee of this invention.
When an attempt is made to overwrite a file in a WINDOWS 9x operating system (hereinafter “WINDOWS”), sometimes the file is in use, or “busy”, and hence cannot be overwritten. Some files are in use as soon as WINDOWS starts, so it is necessary to perform overwrites to these files prior to WINDOWS using the file. Microsoft created a Wininit.ini file to facilitate such file updates. In particular, when an attempt is made to overwrite a busy file, a corresponding entry indicating the overwrite or update, to be performed, is made in the Wininit.ini file. Each entry indicates the destination file (i.e., the file to be overwritten) and a source file containing the data with which the destination file is to be overwritten. Each time WINDOWS is booted, the file updates scheduled in the Wininit.ini file, if such a file is present, are executed line-by-line from top to bottom.
A notable deficiency of the foregoing solution is that no date or version checking is performed when the scheduled updates are performed. This becomes a problem when Wininit.ini contains two entries pertaining to the same destination file. In cases such as this, both source files may be newer than the destination file, but there can be no guarantee that the entry corresponding to the newest source file(if the source files are different) will be listed last in Wininit.ini and thus used to overwrite the destination file last. As a result, it is possible that the computer system could include an older version of the particular file than an application or driver is expecting. This problem occurs quite often in connection with the factory-installation of software, due to the fact that a build-to-order (“BTO”) computer system manufacturer is capable of shipping a computer system having almost any combination of applications and drivers, which often share common files.
For example, in one manufacturing environment, a “PARTS” file for a BTO computer system contains a list of software “parts” identified by part number to be downloaded from a factory server and installed on the computer system. These parts, which are installation packages for various applications and drivers, are installed on the computer system in the order in which they are listed in the PARTS file for the computer system. It is common for each of these packages to attempt to update certain system files during installation thereof. As described above, when the files to be updated are busy, as will be the case with WINDOWS system files, the updates are scheduled in a recognized manner using the Wininit.ini file. A potential problem arises in cases in which two different installation packages make schedule updates to the same destination file. In this case, if the package that is installed last happens not to contain the newest update to the destination file, an application or driver that was installed earlier and expects a newer version of the file might not function properly.
One solution to this problem has been to drop the source file contents directly into the zip file to be applied during system download prior to setting up WINDOWS. This ensures that the destination file will be updated because there is no chance of it being busy at this point. Unfortunately, this method can result in newer versions of the file to be overwritten, because the manufacturer's implementation of the PKUNZIP utility may not perform date/time stamp or version checking. In addition, a long filename directory cannot be created in DOS, so if the file to be unzipped needs to be in such a directory and the directory is not already in existence, the method will not work. Finally, this method requires file updates to be made before operating system (“OS”) setup is performed, whereas the OS might require the original (i.e., older) versions of a file in order to set up properly.
An alternative solution to the above-described problem is to change the order in which the software is installed on the computer system. However, while this alleviates the problem between conflicting scripts, it could result in a new set of files being affected by the aforementioned Wininit.ini problem.
Finally, it would be possible to make a separate patch containing only the file to be applied and have it execute after the next WINDOWS boot. Unfortunately, this technique requires additional work each time the problem is encountered and can be subject to the same problems described above, due to its dependence on Wininit.ini if the file to be overwritten is busy.
Therefore, what is needed is a system for ensuring scheduled file updates are applied with regard to previously existing versions and multiple instances of said updates.
SUMMARY
One embodiment, accordingly, provides a method and apparatus for ensuring that file updates scheduled in a Wininit.ini file are applied with regard to previously existing versions and multiple instances of such updates. In one aspect, a computer program is installed on a computer system and executed after all file update entries have been made to a Wininit.ini file, but before the computer system is rebooted. If duplicate entries exist in the Wininit.ini file for a single destination file, the computer program determines which entry contains the newest source file based first on the version of the source file, if any, and then on the date/time stamp for the source file. The Wininit.ini entries referring to older source files, as well as the files themselves, are then marked for deletion and/or deleted before the computer system is rebooted. In the event that the destination file is the newest version of the file, all entries referring to the destination file, as well as corresponding source files, will be marked for deletion and/or deleted before the computer system is rebooted.
A principal advantage of this embodiment is that it ensures that the newest version of a file is installed on a computer system.
REFERENCES:
patent: 5537592 (1996-07-01), King et al.
patent: 5568639 (1996-10-01), Wilcox et al.
patent: 5600834 (1997-02-01), Howard
patent: 5778395 (1998-07-01), Whiting et al.
patent: 5806078 (1998-09-01), Hug et al.
patent: 5873097 (1999-02-01), Harris et al.
patent: 5894571 (1999-04-01), O'Connor
patent: 6067567 (2000-05-01), Bartfai et al.
patent: 6076105 (2000-07-01), Wolff et al.
patent: 6178428 (2001-01-01), Pystynen et al.
Ayyagari Vamsi
Smith T. Gaven
Breene John
Dell USA L.P.
Haynes and Boone LLP
Pham Linh M
LandOfFree
System and method for ensuring proper execution of scheduled... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for ensuring proper execution of scheduled..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for ensuring proper execution of scheduled... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2858648