Apparatus and Method for Disaster Recovery of an Operating System Utilizing Long File and Directory Names

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

The present invention relates generally to operating systems and more particularly to a system and method for disaster recovery of an operating system, the operating system utilizes a long file and directory naming convention.

Tape backup systems are provided to protect data files and other information from computer system failures such as hard disk crashes or computer virus attacks. A tape backup system stores this data on off-line media (i.e., the tape); this data can then be retrieved in the event of data loss. An example of a conventional backup system is described in U.S. Pat. No. 5,276,860 entitled "Digital data processor with improved backup storage."

The current trend in operating systems for personal computers is to accommodate long file names. This is thought to give the end-user more flexibility in naming directories and files, as well as provide for more descriptive filing systems. Operating systems which provide a long file naming convention also provide the more standard 8.3 filename convention (sometimes called "short" file names). This facilitates the transition to the newer long filename system as well as providing some backward capabilities for future developments.

A problem with the long filename system is that there is no clean way to provide for disaster recovery. For example, operating systems which use the long filename convention are typically too large and complicated to fit on a single boot disk. The term "disaster recovery" refers to the process an end-user must use to restore the computer's files and directories after experiencing a disk failure. Presently, when a disk failure occurs, the end-user must first re-install the operating system before running a backup application to access data on the backup tape. There is a need in the industry to provide for a more efficient and speedy disaster recovery process for an operating system utilizing a long filename convention.

The present invention provides an apparatus and method for disaster recovery of an operating system without having to reinstall the operating system. The operating system utilizes long file and directory names. A converter is provided to permit a DOS or Windows-based program to manipulate files between a system using a conventional 8.3 filename construct and a system using long file and directory names. A software library, coupled to the converter, facilitates running backup applications from a 8.3 filename system. The library contains procedures which allow the 8.3 filename system to create files and directories using the long filename convention, thus recovering from a disk failure.

FIG. 1 shows a block diagram of a general purpose digital computer system incorporating the present invention.

FIG. 2 shows a block diagram of a system for archiving data from a computer system to a tape backup system.

FIG. 3 shows a block diagram of a converter according to the present invention.

FIG. 4 shows a flow chart of the overall flow of the method according to the present invention.

FIG. 5 shows a more detailed flow chart of the present method.

Briefly, the present invention provides a system and method for facilitating the manipulation of long file and directory names by a program characterized by the 8.3 filename convention. Application programming interfaces (APIs) are provided so that DOS or Windows-based program can create, delete, read and write files using the long filename convention. Windows is available from Microsoft Corporation, Redmond, Wash.

FIG. 1 shows a block diagram of a general purpose digital computer system 100 incorporating the present invention. A processing unit 110 is connected to system bus 105. The system bus 105 facilitates communications between the processing unit 110 and memory 120, a data storage disk 130, an input/output interface device 140 and a tape backup system 150. In a preferred embodiment, the memory 120 stores the software of the present invention as well as all data collected and generated by the present invention. In another preferred embodiment, the software may be stored in the data storage disk 130.

An area 125 within the memory 120 is set aside for storage of the present method which is described more fully below. The input/output interface device 140 controls data communications between the bus 105 and a point-and-click mechanism 142 (e.g., a mouse, or a light pen), a display mechanism 144, and a keyboard 146. In a preferred embodiment, the tape backup system 150 can be any number of tape drives available from Hewlett-Packard Company, Palo Alto, Calif., USA, including the Jumbo 1400, Colorado T1000e and Colorado T4000s tape drives.

FIG. 2 shows a block diagram of the present system for automatically archiving data from a computer system to a tape backup system. A scheduler 210 controls an automated backup mechanism 220 via control links 212 and 214. The scheduler uses system status information available from a hard disk 230 via link 231 to determine, among other things, what control signal to send to the backup mechanism 220. For example, if the scheduler 210 determines, based upon the system status 231, that a full backup is required, an ENABLE.sub.-- FULL signal is sent to the backup mechanism 220 via link 212. The ENABLE.sub.-- FULL signal causes the backup subsystem to make a complete archival copy of the hard disk 230 to the tape backup system 150. An ENABLE.sub.-- MODIFIED signal is sent via link 214 when an incremental backup is required. In a preferred embodiment, when the automated backup system is installed, a restore disk is created which contains the present method.

Information contained in a list library 240 is used to determine which files to access when the end user requests that the data archived to the tape backup system 150 be restored to the hard disk 230. The scheduler 210 and automated backup mechanism 220 can both be implemented with any suitable logic, for example, as a state machine in a conventional field programmable gate array (FPGA) with the functionality described above. Additionally, both can be implemented in an application-specific integrated circuit (ASIC), using conventional ASIC fabrication techniques.

FIG. 3 shows a block diagram of the converter according to the present invention. The converter 310 is disposed between system.sub.-- A 301 and system.sub.-- B 302. System.sub.-- A 301 utilizes conventional 8.3 file and directory names; system.sub.-- B 302 utilizes long file and directory names. In a preferred embodiment, the long file and directory names are compatible with the Windows/95 file system, available from Microsoft Corporation. The Windows/95 file system was implemented to maintain backwards compatibility with the existing FAT.sup.1 file system disk format, supporting both 8.3-based filenames and the long filename convention. A long filename may contain up to 255 characters, not including a trailing NULL character. Long filenames may include embedded spaces and characters not permitted in the more conventional 8.3 filename convention (e.g.,:,+,;,=). The full path for a long file and/or directory name can be up to 260 characters. Long names are implemented using multiple directory entries.

A "DOSLFN.LIB" software library 320 is coupled to the converter 310. In a preferred embodiment, DOSLFN.LIB is built using the MSC7.0 compiler and the MASM 6.10 assembler. DOSLPN.LIB contains procedures which allow the 8.3 filename system to create files and directories using the long filename convention. The converter 310 permits a DOS or Windows-based program to create, delete, open, read and write files and directories from system.sub.-- A 301 to system.sub.-- B 302.

FIG. 4 shows a flow chart of the overall flow of the method according to the present invention. A computer system, such as item 100 in FIG. 1, operates normally at block 401. A poll is taken at decision block 402 to determine if a disaster has occurred. If nothing disastrous has occurred, block 401 maintains control of the system. If a disaster is detected, block 410 initializes a recovery procedure. Block 420 first recreates the files and directories using external API's contained in DOSLFN.LIB. These files and directories are then transformed by block 430 using the internal API's from DOSLFN.LIB. Appendix A contains both the external and internal API's according to the present invention. Finally, block 440 restores the system and passes control back to block 401.

FIG. 5 shows a more detailed flow chart of the present method. Block 510 calls the initializing routine, doslfn.sub.-- Initialize.oval-hollow.. This routine allocates memory, initializes variables and creates a unique subdirectory immediately off the root disk directory. This subdirectory is used as a temporary storage location to create files and directories before file relocation as discussed below.

After doslfn.sub.-- Initialize.oval-hollow. is called, block 520 creates files and directories using the 8.3 filename convention. DOSLFN.LIB is implemented so as to take advantage of the underlying DOS file and directory functions where possible. Thus, block 520 utilizes DOS functions to create the files and directories with 8.3 filenames. These newly created files and directories are stored in the temporary subdirectory created by doslfn.sub.-- Initialize.oval-hollow..

Block 530 converts each 8.3 directory entry into multiple directory entries using the long filename convention. Once the long filename directory entries are created, block 540 relocates these entries down to the correct location on the disk to reflect the long path where the multiple directories entries belong. This is accomplished by dividing the desired path into separate path elements and then locating each path element by searching for their associated directory entry. For example, suppose one needs to restore the file ".backslash.A.backslash.B.backslash.C.backslash.a long filename". The present method would divide this into two basic elements: the path ".backslash.A.backslash.B.backslash.C"; and the file "a long filename". An updated cluster number is maintained to determine the destination cluster where the long file and directory name entries should be placed. Each of the steps are then repeated until each of the files that need to be restored are.

While the present invention has been illustrated and described in connection with the preferred embodiment, it is not to be limited to the particular structure shown. It should be understood by those skilled in the art that various changes and modifications may be made within the purview of the appended claims without departing from the spirit and scope of the invention in its broader aspects. ##SPC1##