Electrical computers and digital processing systems: support – Digital data processing system initialization or configuration
Reexamination Certificate
1999-09-16
2002-12-10
Lee, Thomas (Department: 2185)
Electrical computers and digital processing systems: support
Digital data processing system initialization or configuration
C713S001000, C710S008000, C710S010000
Reexamination Certificate
active
06493822
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates in general to a programable apparatus and method for assigning drive letters without conflicts to resource devices in a data processing system based upon three identification numbers assigned by the data processing system's operating system to the resource devices.
BACKGROUND OF THE INVENTION
Many operating systems adhere to the convention of using drive letters to identify accessible resources such as floppy disk drives, CD-ROM drives, and hard drives. Hard drives may be divided into partitions, in which case each partition on the hard drive may be treated as a separate resource. Single drive letters from A to Z are assigned to such resources and are utilized to permit system access to them.
Generally, drive letters are associated with resources during system initialization. In some operating systems, an attempt is made to ensure that each resource receives the same drive letter each time the system is booted. In this case, the drive letter assigned to a resource is said to be “sticky”, and may be chosen by the user or by the operating system itself. Other operating systems do not adhere to this convention, and instead associate drive letters with resources based upon BIOS settings and/or the order in which the resources were discovered by the operating system. For operating systems of this type, simple configuration changes (such as the creation of a partition on an existing hard drive in the system or the addition of a new hard drive to the system) can result in changes to the drive letters associated with resources.
Consistently assigning the same drive letter to a specific resource ensures that the system will boot. If the operating system was installed on a specific resource, its configuration files will often refer to that resource by the drive letter assigned to that resource. Should that drive letter change, the configuration files of the operating system will refer to the wrong resource and the system may not boot. Additionally, most application software utilizes configuration files. If these configuration files reference resources specifically (using their drive letters), then a drive letter change in the system may result in application software failures. Therefore, the drive letters associated with resources should remain the same.
For operating systems employing “sticky” drive letters, there are two basic methods for associating a drive letter with a device. The first is the centralized database approach and the second is the distributed database approach. As this invention is not applicable to the centralized database approach, only the distributed database approach will be discussed.
In the distributed database approach, when a drive letter is assigned to a resource, configuration data containing that drive letter is written to the resource. When the operating system is booting, it merely has to read the configuration data on a resource to determine which drive letter to assign to the resource. Since the drive letter assigned to a resource is stored on the resource, it will exist as long as the resource exists. Furthermore, it is unaffected by configuration changes, such as a change in how the resource is connected to the system or the creation of a new partition on an existing drive in the system. However, drive letter assignment conflicts become possible if resources are moved from one system to another. If a resource is moved from one system to another, and if that resource contains the same drive letter assignment as an existing resource in the new system, the operating system must decide which resource actually gets the drive letter. An incorrect choice could result in a failure to boot. To assure the ability to boot, conflicts must be resolved in favor of existing resources in the system (“native” resources) and against resources which are “foreign” to the system ( i.e. a resource that was just moved to the system and which has not yet been assimilated). Therefore, a way of determining which resources are native and which resources are foreign is needed.
U.S. Pat. No. 5,815,705 discloses a drive letter conflict resolution system for resolving conflicts that occur when the operating system attempts to assign a drive letter to a compressed volume file.
U.S. Pat. No. 5,809,329 discloses a method of assigning a unique code to each device detected in the system. This device code consists of a system bus code which uniquely identifies the system bus where the device was found, and a unique device code which identifies the device on the bus where it was found. The bus code is then appended to the device code to produce the final code which is then used to uniquely identify the device. Logical configuration data is collected and resources are allocated based on the device identifying code and the logical configuration data. It should be noted, though, that the device code produced by this method will change if the device is moved from one bus in the system to another.
U.S. Pat. No. 5,896,546, discloses a method in which logical drive letters are assigned to a peripheral device in a computer using stored identifying information and a corresponding preferred drive letter assignment for each peripheral device having a preferred drive letter assignment. During initialization of the data processing system, identifying information such as a physical device specifier or a logical volume identifier is derived from the way the peripheral device is connected to the system. This identifying information is compared to similar stored identifying information in a central database. If a match is found, the peripheral is assigned the corresponding preferred drive letter, if possible. It should be noted, though, that the device identifier used by this method will change if the device is moved from one bus in the system to another. This could lead to resources not being assigned a drive letter or being assigned the wrong drive letter.
SUMMARY OF THE INVENTION
The present invention solves the problems identified above by introducing a program into an operating system for assigning up to three identification numbers to resources and resolving drive letter assignment conflicts based on these three identification numbers. The three identification numbers are stored on the resource itself, and travel with the resource should it be moved.
The first of the three numbers is called the Resource Serial Number (RSN). This is a unique number used to identify a specific resource. Every resource in a system will receive a unique RSN. The second number is the Boot Drive Serial Number (BDSN). The BDSN of a resource is set once the operating system has determined that it can use the resource. The third number is the Sequence Number (SQN). The purpose of the SQN is to identify which of the “native” resources associated with the system were present the last time a configuration change was made. The SQN of “native” resources is updated everytime there is a configuration change in the system, including any changes in drive letter assignments. Finally, in order for a resource to be considered “native”, its BDSN must match the RSN of the boot resource, and its SQN must match the SQN of the boot resource. Resources without an RSN, BDSN, or SQN, or whose BDSN and SQN do not match the RSN and SQN of the boot resource, are considered to be “foreign”.
In operation, the operating system will use the three identification numbers during boot. If a drive letter conflict arises during system boot, the drive letter conflict is resolved by giving preferential treatment ( and hence the drive letter ) to the resource in the conflict which is determined to be “native” based upon its three identification numbers.
Typically, the RSN, BDSN and SQN of each resource will be assigned when the operating system is installed. When resources are added to a system, the RSN of each new resource will be set immediately while the BDSN and SQN of the new resources will be set when the new resources have been assigned drive letters which do not conflict with those of any exis
Cao Chun
International Business Machines - Corporation
Lee Thomas
Mims Jr. David A.
Siegesmund Rudolf O.
LandOfFree
Foreign drive determination and drive letter conflict... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Foreign drive determination and drive letter conflict..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Foreign drive determination and drive letter conflict... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2979207