Method for accessing and updating a library of optical discs5884298Abstract A method accesses and updates information from a library of optical discs and includes a step of cataloging optical discs. The cataloging step includes the generation of a unique value for each of the cataloged discs. The unique value is produced by iteratively reading data from each disc and iteratively combining the data. The cataloging step includes the generation of catalog data streams. The catalog data streams include fixed length data representing file and directory attributes and variable length data representing file names and directory names. The method includes the further step of producing limited depth catalogs representing file and directory information on the optical discs. The limited depth catalogs have a fixed number of subdirectory levels and file types. The fixed number is selected by a user, and the file types are selected by a user. The method includes the further step of caching optical disc data to a hard disc. The cached data are written to the hard disc when the optical disc data are requested more frequently than other optical disc data. The requests are monitored by a caching file system. The caching file system determines when the requests for data can be satisfied by cached data. The caching file system satisfies the requests by accessing and communicating requested data from the cache. The method includes the step of reconciling actual storage locations of optical discs with storage locations represented in a database. The method includes the step of manipulating physical components of an optical disc library by dragging and dropping icons displayed on a user interface, the icons being associated with the physical components. The method includes the step of displaying an hierarchical index to a user, said index representing the subordinate relationship of the components of an optical disc library. The method includes the step of recording check-out and check-in transactions and maintaining a history of such transactions. Claims What is claimed is: Description This application claims priority from U.S. Provisional Application No. 60/025752 filed on Sept. 19, 1996 and also claims priority from U.S. Provisional Application No. 60/023233 filed on Mar. 29, 1996.
TABLE 1
______________________________________
dwOffset DWORD Offset of first directory entry
dwFileAttributes
DWORD File attributes
ftCreationTime
FILETIME Creation Time/Date of File
ftLastAccessTime
FILETIME Last Time/Date File was Accessed
ftLastWriteTime
FILETIME Time/Date of Last Write to File
nFileSizeHigh
DWORD High order word of file size
nFileSizeLow
DWORD Low Order word of file size
cbName WORD Length of File Name
dwNameOffset
DWORD Pointer to File Name in Name Stream
______________________________________
The second stream comprises a series of textual names corresponding to the names assigned to the files and directories on an optical disc. Each fixed-length data block comprising the first stream has an offset pointer into the second stream marking the point at which a corresponding name begins. Each fixed-length data block also has a name length value establishing the number of characters in the name. One of ordinary skill in the art will appreciate that a pointer into a text stream and a value corresponding to a number of characters are sufficient to determine a text string--in this case, a name. To create a new record for the directory database, the Directory Server first creates a Fingerprint Identifier (FID or TitleID) that identifies the optical disc associated with data in the new record. The Fingerprint Identifier (FID) advantageously provides a compact, rapidly generated, binary tag uniquely distinguishing optical discs in an optical disc library. A 32-bit (4-byte) hash value which results from calculating a checksum of disc volume label and operating system-independent attributes of all files in the root (highest level) subdirectory is preferably generated in the following manner: (1) The characters of the disc volume name, in groups of 4, are accumulated across the corresponding four bytes in the checksum value until the volume name is exhausted; (2) For each file or subdirectory present in the root directory of the disc, the least significant four bytes of the file size are accumulated in the corresponding four bytes in the checksum value; (3) The characters of the file or subdirectory name, in groups of 4, are accumulated across the corresponding four bytes in the checksum value until the name is exhausted; and (4) The four bytes of the file modification date and time (in a standardized 32-bit representation described below) are accumulated in the corresponding four bytes in the checksum value. Accumulation is a process where numbers are added to each other and the sum is rendered using a fixed number of least significant digits, discarding the most significant digits. Importantly, because a FID is generated directly from physical data on the optical disc (i.e., is content-based), it can be advantageously used to resolve ambiguities related to disc identity or location. Other permutations of the FID generation method are presently possible, and as optical disc data formatting standards evolve in the future, the FID generation method is easily adapted to new formatting standards and, thus, is not limited by a formatting standard. Nor is the FID generation method limited to the specific checksum method described above: differing selections of optical disc content may be incorporated into this or some other FID generation method. Because FID values uniquely identify optical discs, they are advantageously used to detect the presence of duplicate optical discs residing in the same library. An optical disc management system is made more efficient by taking advantage of duplicate optical discs. For example, a single catalog data structure is used to satisfy catalog inquiries performed on different but duplicate discs. Also, when a user requests access to an optical disc which is unavailable, a duplicate of the requested disc is loaded automatically. Once a FID has been created in a step 408, FIG. 4A illustrates a next step 409 wherein the Directory Server scans records in the directory database to determine whether a newly created FID matches any previously recorded FID (i.e., whether the optical disc being introduced into the optical disc management system may have already been introduced at a prior time). One skilled in the art will understand that, because FIDs are numeric values, many different methods exist to determine whether one FID exists among a database of FID values, particularly when, as in the preferred embodiment, the FID is used as a key to index records in the directory database. If, in a step 410, a newly created FID is found to be unique (e.g., does not exist in the directory database of previously stored FID values), the Directory Server then, in a step 412 acquires file and subdirectory descriptor blocks directly from the optical disc and, before storing the file and subdirectory information from the optical disc into the directory database, the Directory Server performs transformations on the file and subdirectory data. The Directory Server compacts the data representing file and directory information into the two-stream format (described above) which can be efficiently searched (e.g., by scanning the name entries without scanning other file information). As illustrated in FIG. 4A, once the data representing file directory and file information has been compressed into a directory database representation (the two-stream format), the Directory Server in a step 414 stores the two streams in a record in the optical directory database and indexes the compressed binary file image using the unique FID as a primary key. Key-based indexing of data within databases (including indexing data by multiple keys) is common in the art and will not be described further herein. In another embodiment of the optical disc management system embodying the present invention, a file is created having a filename generated using the FID, and the two streams comprising a directory database are stored in the file. Thus, a single representation exists for each optical disc in an optical disc library, each representation comprising directory information for a single optical disc. Control next transfers to the optical disc Title Server. The Title Server creates and updates records in the title database. The fields comprising each data record of the title database are described in Table 2.
TABLE 2
______________________________________
FIELD TYPE DESCRIPTION
______________________________________
TitleID Character(28)
Unique Identifier for Optical Disc
Name Character(128)
Description of Optical Disc
VolName Character(11)
Volume Name
VolSerial
Numeric(11,0)
Volume Serial Number
Format Numeric(2,0)
Digital Format Identifier
FileSys Character(12)
File System Name
DirID Character(8,0)
Directory Fingerprint Identifier
LoadedID
Character(28)
Last Loaded ID
LoadedTS
Character(14)
Last Loaded Time
LoadCnt Numeric(11,0)
Load Count
OwnerID Character(28)
Owner ID
Code Character(10)
Password
CodeID Character(28)
Password ID
COutID Character(28)
Check Out ID
COutTS Character(14)
Check Out Time
CInTS Character(14)
Check In Time
Category
Character(64)
Subject Category
AutoLoad
Numeric(1,0)
Autorun Enabled
RunCmd Character(254)
Default Run Command
User0 Character(25)
User Field 0
User1 Character(25)
User Field 1
User2 Character(25)
User Field 2
User3 Character(25)
User Field 3
User4 Character(25)
User Field 4
User5 Character(25)
User Field 5
MagTray Character(30)
Magazine ID + Tray Number
ExchrRdr
Character(28)
Exchanger and Optical Drive Number
CreateTS
Character(14)
Creation Timestamp
ModifyTS
Character(14)
Modification Timestamp
CatTS Character(14)
Catalog Timestamp
CatDepth
Character(4)
Catalog Depth
CatFlags
Character(4)
Reserved
CreateID
Character(28)
Created by ID
ModifyID
Character(28)
Modified by ID
______________________________________
The Title Server, in a step 416, issues a request to the computer operating system to return a 128-bit statistically unique identifier (UID) in preparation of creating a new record in the title database. Other methods of obtaining statistically unique values are known in the art, and no part of this invention is limited by any particular computer operating system. The Title Server verifies the UID is unique in the title database by checking whether the UID already exists in the title database, and, if necessary, repeatedly requests new UIDs from the computer operating system until a unique UID (one not in the title database) is generated. Next, the Title Server, in a step 418, assigns attributes to (fills in the various fields of) the title record. In a next step 419, the title record is indexed by the UID as primary key and the FID as foreign key, and the new record is committed to the title database. Upon the completion of the step 419, the optical disc is uniquely identified and its physical attributes and contents are represented in the title and directory databases, respectively. The cataloging function performed by the Directory Server and Title Server terminates in a step 420. If, in the step 410, a newly created FID is found to exist already in a record of the directory database and is therefore not unique, then the Title Server, in a step 422 as illustrated in FIG. 4B, gathers all title database records with a matching FID value and presents to the user, in a step 424, a list of the optical discs already present in the library having a FID identical to the newly created FID (a "disc duplicate" list). At this point, in a step 426, the user may (1) cancel the cataloging function (e.g., in the case where, for example, the user determines that the newly loaded optical disc has already been cataloged); (2) proceed with the creation of a new title record; or (3) manually assign the identity of the optical disc to be cataloged by selecting a preexisting record from the title database (selecting one of the optical discs shown in the disc duplicate list) and thereby reassign the location of the optical disc represented by the chosen record. If the user cancels the cataloging operation in the step 426, then in a next step 420, the fingerprint and directory cataloging function of the Directory Server terminates. If, however, in the step 426, the user intends to create a new title record to associate with the optical disc to be cataloged, then the Title Server, in a step 428, assembles and adds a new title record to the title database according to the steps 416-420. If, in the step 426, the user informs the optical disc management system software that the optical disc to be cataloged is already represented by an existing title record, the location of the existing optical disc may be verified and/or updated. Because a storage location (the location containing the optical disc immediately before it was transferred by hand or by jukebox into an optical disc drive) is known for the optical disc, that location can be recorded in association with information identifying the optical disc. Thus, in a step 430, the existing record in the title database for the optical disc is updated to associate a physical storage location with other information about the optical disc. The cataloging function provided by the Directory Server and the Title Server then terminates in a step 420. FIGS. 5A and 5B comprise a flowchart illustrating the steps of creating a limited-depth optical disc catalog in the directory database. The limited-depth catalog represents files and directories of an optical disc and is browsed by users to determine the contents of the target optical disc. In a first step 502 illustrated by FIG. 5A, the user is prompted by the Directory Server specify cataloging parameters, such as maximum number of subdirectory levels, file types and a list of file names (including wild card-based filename patterns, such as where a filename of "od*.*" indicates every file whose name begins with the string "od"). It will be appreciated by one skilled in the art that other criteria could be specified to identify directories or files such as, for example, size range, date range, etc. Once the catalog criteria have been specified by the user, the Directory Server determines, in a step 504, whether the specified criteria are valid by determining whether at least one file or directory entry is indicated by the specified catalog criteria. If, in the step 504, no directory or file entries on the optical disc are indicated by the specified criteria, the Directory Server repeats the step 502 of prompting the user to specify catalog criteria (note that the re-prompt on zero files may be activated or deactivated by the user). Other cases where catalog criteria are invalid, include, for example, the case in which the user specifies a maximum subdirectory depth of less than one or greater than the maximum allowed by the file system. Because such criteria are treated as invalid, the user, in the step 502, is again asked to enter catalog criteria. If, in the step 504, the catalog criteria are determined to be valid, the Directory Server, in a next step 506, uses those criteria to assemble an in-memory binary structure which represents those criteria and against which each acquired file or subdirectory descriptor block is tested. In a step 508, the Directory Server begins to recursively scan file and subdirectory descriptor blocks on the target optical disc. The Directory Server, in a step 510, creates a memory buffer sufficient to store incoming file and subdirectory descriptor blocks according to specified catalog criteria. In a step 512, the Directory Server, using a standard operating system service, requests the descriptor (a group of data associated with a file or directory which describes attributes of the file or directory) for the first file system object matching the user-specified catalog criteria. Next, in a step 514, the Directory Server determines whether the computer operating system successfully provided data about a file or a subdirectory on the target optical disc. If not, the recursive scan ends in a step 516 as shown by FIG. 5B. If the computer operating system successfully provided data about the first file or subdirectory on the target optical disc in the step 514, then, in a step 518, the Directory Server examines the descriptor block to determine whether the descriptor describes a file or a subdirectory. If the descriptor describes a file, then, in a step 520, the Directory Server determines whether the file attributes and name satisfy the cataloging criteria. If the criteria are not satisfied, the information about that file is not cataloged, and the Directory Server, in a next step 522, issues a request to the operating system to return a descriptor block representing the next file system object at the current directory level. If, in the step 520, the catalog criteria are satisfied by the file descriptor information, or if, in the step 518, the file descriptor information was determined to represent a subdirectory, the Directory Server, in a next step 524, performs a binary transformation (as discussed in relation to FIG. 4) on the file descriptor information provided by the operating system to produce a compressed binary image of the descriptor. In a step 526, the Directory Server stores the data comprising a binary transformation of file information in the directory database. Next, in a step 528, if the binary transformed data represent information about a file, then, in a step 530, the Directory Server proceeds to obtain information about the next file or directory at the same directory level by proceeding to the step 522. If in the step 528, the binary transformed data represent a directory, then, in a step 532, the Directory Server checks whether a lower subdirectory exists. If a lower subdirectory exists, then, in the step 534, the Directory Server moves to the indicated subdirectory level and recurses to step 522 to request from the operating system the next file or subdirectory descriptor of the next lower directory. If no lower subdirectories exist, however, in the step 532, then the Directory Server, in a step 536, proceeds to obtain the descriptor for the next sibling file or directory at the same directory. The Directory Server then, in the step 522, requests additional information from the operating system about the next sibling file or subdirectory in the current directory level. Thus, a limited catalog is created which represents the files and directories on an optical disc. The Directory Server permits a user to modify the cataloging criteria, and in addition, replace the directory catalog record for any optical disc with a new catalog record if the cataloging criteria on which the original catalog record was based is different from the new catalog criteria. In the case when available storage media is limited, replacement of directory catalog records with new directory catalog records representing fewer subdirectory levels results in the use of less storage media. Also, alternatively, if available storage capacity increases (e.g., additional or larger hard disk drives are connected and made available), then subsequent creation of catalogs could be performed to produce catalogs having greater numbers of levels, offering users more complete views of the directory and file information for each cataloged optical disc. A graphical user interface embodying elements of the present invention presents both a hierarchical display and a tabular display of information in an optical disc library. The physical components of an optical disc library have a subordinate relationship: Optical disc jukeboxes hold magazines, magazines hold optical discs, optical discs hold files and directories, directories hold files and subdirectories, and subdirectories hold files and additional subdirectories. This subordinate relationship is represented by icons comprising a hierarchical presentation of the physical components of an optical disc library. FIGS. 6, 7A, 7B, 8A, and 8B illustrate a graphical user interface embodying elements of the present invention. The graphical user interface provides views of the optical disc directory information and associates the views with icons (pictorial bit map images) which represent the various elements comprising the optical disc management system. FIG. 6 illustrates icons representing physical components of an optical disc library system. A first optical disc jukebox (a local or private jukebox) to which a single computer has exclusive access is represented by an icon 602. A second optical disc jukebox which is accessible to multiple computers on a network is represented by an icon 604. An icon 606 also represents an off-line magazine shelf. The off-line magazine shelf represents a collection of optical disc magazines which are not presently loaded into optical disc jukeboxes, but which are indexed by the optical disc management system. To examine the contents of a jukebox or a magazine shelf, a users clicks on an expand/collapse icon 610 located immediately to the left of the jukebox icon 602, 604 or magazine shelf icon 606. The hierarchical display is then updated to show the magazines associated with a jukebox or magazine shelf. If, for example, the magazine shelf is expanded, the magazines associated with it are illustrated by magazine icons 608 appearing immediately below the magazine shelf icon 606 and indented slightly to the left of the magazine shelf icon 606 to show the subordinate relationship. By clicking the same expand/collapse icon, the user causes the magazine icons associated with the magazine shelf to be removed from the display (i.e., collapsed back into the magazine shelf). Note that when the magazine shelf is in a collapsed state, the expand/collapse icon preferably presents a plus "+" sign to the user indicating that the magazine shelf can be expanded. However, when the magazine shelf is illustrated in an expanded state as illustrated in FIG. 6, then the expand/collapse icon presents a minus "-" sign to the user indicating that the magazine shelf can be collapsed. A user examines the contents of a magazine represented in the hierarchical display by the magazine icon 608 by clicking on an expand/collapse icon located immediately to the left of the magazine icon 608. Clicking the expand/collapse icon to the left of the magazine icon 608 causes the display to change such that icons representing each individual optical disc associated with the magazine will appear immediately below the magazine icon, but indented to the right to show the subordinate relationship between the optical discs and the magazine. Clicking the expand/collapse icon again will cause the icons representing the optical discs to be removed from the display. The hierarchical display represents multiple levels of subordinate information. Files and directories comprising an individual optical disc are browsed by clicking an expand/collapse icon to the left of an icon representing an optical disc, and directories and subdirectories on an optical disc are similarly browsed by clicking on representative icons to reveal or expose subordinate files and directories. Those of ordinary skill in the art will understand that an embodiment of the present invention may include any media transport device storing removable, computer-readable media, and that information stored on the computer-readable media could be similarly cataloged and browsed in an hierarchical fashion. FIG. 7A illustrates a graphical user interface comprising icons which represent components of an optical disc library. An icon 702 represents a robotic optical disc jukebox and an icon 704 represents an optical disc storage magazine. FIG. 7A, through the arrangement of representative icons, shows the hierarchical relationship of an optical disc jukebox and the optical disc storage magazines which are located inside the jukebox. The jukebox icon 702 is located above and to the left of the magazine icon 704, indicating that the magazine represented by the magazine icon 704 is subordinate to the jukebox represented by the jukebox icon 702. Each icon having the same horizontal displacement from the left edge of the computer screen (at the same indent level) thus represents a physical component of an optical disc library which is subordinate to another physical component represented by the nearest icon positioned above and to the left of the respective icon. FIG. 7B illustrates a tabular view 708 of information describing the contents of optical discs stored in a single optical disc storage magazine. A user obtains a tabular view of optical disc library contents by selecting a VIEW option 706 illustrated in FIG. 7A, and then selecting, for example, a TABULAR VIEW suboption from a drop-down menu. Alternatively, a user obtains a tabular view of the contents of a directory, optical disc, magazine, or a jukebox by using a mouse to position the on-screen pointer on top of the icon representing the physical device, clicking and holding down one of the mouse buttons, and moving the mouse to drag the icon underneath the mouse pointer such that it rests on top of a second icon 710 representing a browsing dock. The function of the browsing dock is discussed in more detail below. Both the hierarchical and tabular views illustrated in FIGS. 7A and 7B are created by accessing data from the directory database and the title database. The directory database comprises information describing files and directories on optical discs, and the title database comprises information describing the location of an optical disc (e.g., the tray of a magazine occupied by the optical disc, the magazine bay in a jukebox occupied by the magazine). Those of ordinary skill in the art will appreciate that extracting data from a database and presenting the extracted data in a manner formatted to fit within a window of a graphical user interface is known in the art and thus will not be further described. FIG. 8 illustrates a drag and drop method for manipulating various physical components of a removable media management system, including but not limited to, optical discs, optical disc drives, and robotic optical disc jukeboxes. This drag and drop method is provided by the graphical software user interface. Drag and drop user interface controls are known in the art. However, an important advantage and novel feature of the present invention is the manipulation of physical components of an optical disc library resulting directly from user drag and drop operations. This includes, but is not limited to, physically retrieving the optical disc medium from a storage location by a medium transport element, loading the medium into a data I/O device, unloading the medium to the transport element, and depositing the medium into a storage location. Other operations are also provided which may not directly result in robotics activity, such as selected rendering of data, including data describing locations of library components as well as data comprising indexes of optical media or content of optical media. These operations may also be initiated using the drag and drop technique. For example, positioning an on-screen computer pointing device (preferably with a mouse) over a magazine icon 802, then holding down a mouse button while positioning the pointer over a browse dock icon 804 (visual feedback shows an icon representation of the magazine moving or dragging along with the mouse pointer), and then releasing the mouse button causes the display to change from a hierarchical display 806 to an expanded hierarchical display 808 describing the optical discs located in the magazine represented by the icon 802. In effect, the contents of the magazine represented by the moveable icon 802 are expanded to a detail view using the drag-and-drop process. These techniques are novel in the art in relation to the data associated with removable media. FIG. 8B illustrates a drag and drop operation which directly results in robotics activity. The mouse pointer is positioned over an optical disc icon 810, the mouse button is depressed, the mouse pointer is moved, thus dragging the icon 810 so that it is positioned over an icon 812 representing an optical disc drive. One of ordinary skill in the art will appreciate that a proximity of two icons creates a determinable event when the distance between the two icons changes from greater than the trigger distance (a specified threshold distance from a drop target icon) to less than or equal to the trigger distance. In a preferred embodiment of the present invention, a trigger distance of zero creates a determinable event when the two dimensional space of a drag source icon touches the two-dimensional space of a drop target icon. Releasing the mouse button while the optical disc icon 810 is positioned over the optical disc drive icon 812 causes media transport commands to be issued to a robotic optical disc jukebox. The media transport commands cause a medium transport element of the robotic optical disc jukebox to physically retrieve the optical disc represented by the icon 810 from a physical magazine represented by the magazine icon 802, and to deposit the optical disc into the optical disc drive represented by the icon 812. Further, if an optical disc is occupying the targeted optical disc drive but is idle (not in use), the idle disc is transferred to a storage location by the medium transport element, prior to the retrieval, transportation, and loading of the newly selected optical disc represented by the icon 810. Thus, physical retrieval, transportation, loading, unloading, and storage of removable media is accomplished by the drag and drop control of the present invention as embodied by the described graphical user interface. One embodiment of the present invention employs two-dimensional truth tables to describe every valid drag and drop icon interaction. The object-oriented design of the client application software is particularly amenable to reconciling drag source/drop target communication and ensuing program behavior. Physical components of an optical disc library are each represented by an object (a variable comprising both functions and data). Each object is capable of rendering an icon to represent itself (according to state attributes) in the graphical software user interface. If an object is endowed with drag source behavior, it renders an icon which moves on screen as it is being dragged, and differentially renders the on screen image to indicate acceptance or rejection by a potential drop target object. Similarly, if an object is endowed with drop target properties, it monitors and detects queries originating from drag source objects whose icons share screen pixels with its own icon, and according to the specific software application design rules, determines which objects may be accepted in existing operational state(s) and/or context(s), and which objects may be rejected. Note that an object with drag source behavior may or may not also possess drop target behavior, and that an object with drop target behavior may or may not also possess drag source behavior. A drag and drop interaction, or conversation, occurs when an icon rendered by an object having drag source behavior, is moved to a position on the screen also occupied by an icon rendered by an object having drop target behavior. In a given drag and drop conversation, the drag source object queries the drop target object for drop acceptance. A potential drop target object discovers the nature and operational state and context of the querying drag source object by examining various data comprising a query packet transmitted to the drop target object by the drag source object. The potential drop target object responds to the drag source object's query with a result indicating acceptance, rejection or a conditional rejection at the current location of the pointing device. If the response is acceptance and the mouse button is released, both the drag object and the drop target receive a `drop` event. The drag source object responds to a drop event by transmitting data necessary to perform an associated operation. The drop target object responds to the drop event by invoking methods of the drag source object or by invoking its own methods, or both, as needed to perform an associated operation. Many combinations of valid drag and drop operations result in a series of commands being communicated to a robotic optical disc jukebox such as that described below (see FIGS. 18-22). One skilled in the art will understand that the present invention is not limited by a robotic optical disc jukebox, but applies also to any media transport device capable of transporting computer-readable media from storage locations to a reading or writing device or vice versa. Data records store associations between individual optical discs and physical storage locations. Thus, for any optical disc in an optical disc library embodying the present invention, there is an assigned storage location (e.g., tray #3 of magazine #2). The commands generated by dragging an optical disc icon over an icon representing an optical disc drive comprise high level GET and PUT commands which utilize assigned storage locations. For example, if an optical disc icon represents an optical disc stored in tray #3 of magazine #2, and such icon is dragged over an icon representing an optical disc drive, then the commands generated would resemble (1) GET Disc from Tray 3 of Magazine 2 (whereupon the optical disc jukebox retrieves the disc occupying tray #3 of magazine #2); followed by (2) PUT Disc in Optical Disc Drive (whereupon the robotic optical disc jukebox loads the optical disc into an optical disc drive). If the user performs an unload operation by dragging the icon representing the optical disc off the icon representing the optical disc drive, the commands generated would be (1) GET Disc from Optical Disc Drive (whereupon the robotic optical disc jukebox removes the disc from the Optical Disc Drive); and (2) PUT Disc in Tray 3 of Magazine 2 (whereupon the robotic optical disc jukebox stores the disc in tray 3 of magazine 2). One of ordinary skill in the art will appreciate that each of these high-level commands is interpreted into a series of low-level commands to which a robotic optical disc jukebox (or some other media transport device capable of robotically transporting computer readable media) responds. Such interpretation advantageously permits the present invention to control a wide variety of media transport devices. The present invention is not limited to causing physical operations to be performed by robotic optical disc jukeboxes, but can also map valid drag and drop operations into other high-level commands which are, in turn, interpreted into low-level command sequences for transmission to other devices. An optical disc management system embodying the present invention provides a method for caching data on an optical disc to a hard disk. Traditional caches work by storing recently or frequently used disk sectors (of hard disks or floppy disks) in RAM (random access memory). When a process executing on a computer requests data from recently used disk sectors (i.e., sectors that are still cached in RAM), the requested data is delivered to the process directly from RAM, avoiding the need to read from a hard disk or floppy disk. Because seek and transfer operations on RAM are much faster than seek and transfer operations on hard disk or floppy disks, a traditional cache improves system performance. The caching method of the present invention differs from traditional caching in important ways. First, rather than being cached in RAM, data from optical discs is cached on a hard disk. Second, because the hard disk cache medium is non-volatile, cached optical disc information is retained in the cache even when the machine is powered down. Third, instead of caching simple disk sectors, the caching method of the present invention is capable of three different caching modes, which differ in the type and quantity of cached data. In a first caching mode, the entire contents of an optical disc are cached. It is understood in the art that data on a hard disk accessible by a computer network can be accessed by multiple users simultaneously (subsecond differences in access time). Accordingly, this caching mode provides simultaneous, high-speed access to all data of an optical disc for multiple network users. Although this method consumes relatively large quantities of hard disk space, it is the best solution for frequently used optical discs. It also avoids the need to intercept operating system file I/O operations--only the original disc-load operation needs to be redirected to the cached disc image. In another caching mode, frequently-used files or data items are cached from an optical disc to a hard disk. In this caching mode, the caching method intercepts operating-system open-file requests, directs these requests to either an on-line optical disc or to cached files as necessary. This caching mode requires less hard disk storage, but requires the intercepting and redirection of more operating system functions. In still another caching mode, directory information from an optical disc is cached to a hard disk. This caching mode is facilitated by the catalog creation method of the present invention described herein. As such, all directory information (the files and subdirectories) on each cataloged optical disc is cached, and users need not establish specialized caching rules or configure the caching method in any way. By intercepting operating system directory operations (e.g., FindFirstFile, FindNextFile, etc), the caching method redirects these requests to the directory database (described above), enabling much quicker access (especially when multiple network users are accessing the same optical disc). This caching mode avoids optical disc load operations otherwise required to satisfy requests for directory information. Traditional caching methods simply store into a cache the most-recently-used data, and eliminate from the cache the least-recently-used data. The caching method of the present invention utilizes a more sophisticated caching strategy based on usage statistics recorded over time. Using these statistics, caching features of the present invention either automatically decide which optical discs (or portions thereof) to commit to the hard disk cache or present these statistics to a user to facilitate manual selection of optical disc data for caching. FIG. 9 illustrates the steps performed by a caching system to cache optical disc data or portions thereof (including file and directory information) to a hard disk drive. In a step 902, caching rules are established which indicate when information from an optical disc is stored in a hard disk cache. Data comprising optical disc usage information such as, for example, the number of requests received for an optical disc or a portion thereof over a certain time period, are stored in relation to each optical disc. When recorded optical disc usage information meets threshold requirements for caching, then optical disc data is cached. Many different caching rules can be formulated to indicate when optical disc data should be cached. Such caching rules might include, for example, "NEVER CACHE `SETUP.EXE`,""NEVER CACHE COMPRESSED FILES," "CACHE OPTICAL DISC IF REQUESTED MORE THAN 10 TIMES IN 5 DAYS," or "ONLY CACHE INDEX FILES." In a preferred embodiment, information from an optical disc is cached when such information is requested often enough to satisfy threshold frequency-of-use criteria. Once optical disc caching rules are determined, the rules are persisted in a step 904 by writing the optical disc caching rules to non-volatile, computer readable storage media, such as a hard disk. In a step 906, the caching system begins executing. When, in a next step 908, a user or an executing program requests optical disc data, the caching system, in a step 910, determines whether the data requested is already cached. If so, there is no need to cache the data, and in a step 912, normal processing continues by providing the user with data from the cache. If the requested optical disc data is not already cached in the step 910, then, in a step 914, the caching system determines whether a cache "To Do" flag (indicating that optical disc data is to be cached) associated with the requested optical disc data has been set. If so, then the optical disc data is cached in a step 916 (the caching process is described in more detail below), and the caching process terminates in a step 922. If, in the step 914, it is determined that the "To Do" flag is not set, then, in a step 918, the caching system determines whether the frequency-of-use information for the requested optical disc data satisfies the threshold caching rules. If so, then the caching system, in a step 920, sets the "To Do" flag associated with the requested optical disc data indicating that caching is to be performed the next time the optical disc data is requested. Normal processing then follows in a step 922 wherein the data requested by the user is retrieved from the optical disc. If the recorded usage information for the requested optical disc data does not satisfy the threshold caching rules, then normal processing results in a step 922 in which data requested by the user is retrieved from the optical disc rather than a cache. It is important to note that all caching flags indicating the cache status of each optical disc are stored in the optical title database. FIG. 10 is a flowchart illustrating the steps of caching data from an optical disc to a cache on a hard disk drive. In a step 1002, the caching system determines if sufficient free space (unallocated capacity) exists on the hard disk containing the cache to accommodate the optical disc data to be cached. If so, then, in a step 1004, the caching system copies the data from the optical disc to the cache and also sets a flag associated with the optical disc data indicating that the data has been cached. In a next step 1006, normal processing resumes by supplying the data requested from the cache. If there is insufficient storage capacity available on the hard disk to accommodate the data to be cached, then, in a step 1008, the usage information of the requested optical disc data is compared to the usage information associated with each individual cached data item. If the requested data item is determined to be in greater demand than at least one of the cached data items (or, in other embodiments, the requested disc better satisfies the caching rules than a cached disc), then, in a step 1010 the caching system removes from the cache the data item having the lowest demand and also, in a step 1012, sets a flag associated with the removed data item to indicate that the removed data item is not cached. The caching system then, in a step 1014, copies data from the optical disc to the cache and sets a flag associated with the requested optical disc data indicating that the data have been cached. Normal processing then resumes in the step 1006 by retrieving data requested by the user from the cache. If a requested optical disc data item (the entire optical disc or a portion thereof) is not in greater demand than any cached data item, the caching system does not change any flag associated with the requested data item, and thus, the requested optical disc data item, in a step 1016, is a candidate for caching upon the next request for that data item, and, in a step 1006, normal processing resumes by retrieving the data item requested by the user from the optical disc. It is important to note that user-selectable caching of information from optical discs is also provided. A first step in user-selectable caching is that the user issues a command indicating that user-selectable caching is to be performed, to which the user-selectable cache system responds by waiting for the user to select information to be cached from browsable catalog information presented to the user. The user then selects which optical disc or which data from an optical disc is to be cached. At this point, the steps 1002-1016 are performed with one difference. If in the step 1008, the information that the user has selected to cache has a lower demand than any information currently cached, the user will be prompted to select information to be removed from the cache. If the user selects no information to be removed, then the step 1016 is performed. If, however, the user selects information to be removed from the cache, then, in the next step, the selected information is removed and the title database is modified to show that the removed data is not cached. The step 1014 is then performed to copy into the cache the information the user selected to cache. To optimize performance of the optical disc management system by caching information from optical discs, a caching file system is provided which includes a cache-aware Directory Server. FIG. 11 is a flowchart illustrating the steps performed by the caching file system. In a step 1102, all file system requests are monitored including file directory read operations and other file I/O requests. In a next step 1104, the cache-aware Directory Server determines whether the request is a file directory read. If not, then in a step 1106, the file I/O request is passed to the operating system's file I/O services and no further processing is done by the caching file system which then terminates in a step 1110. If, however, the request is a file directory read, then it will be processed by the cache-aware Directory Server in a step 1108. The cache-aware Directory Server then determines whether the information requested resides in the cache, and, if so, locates the information within the cache and transmits that information to the user. Processing by the caching file system then terminates in a step 1110. As described herein, an optical disc management system (ODMS) embodying the present invention maintains databases of information to track the physical location of the optical discs which compose a library. To resolve situations in which the information in the databases is not accurate (e.g., one or more optical discs have been somehow manually relocated by the user within the library hardware), the ODMS includes a reconciliation process. The reconciliation process, described in detail below, is initiated either by a user who knows or suspects that an optical disc in the optical disc library has been somehow misplaced, or by the ODMS whenever an error is encountered wherein an optical disc cannot be found in its assigned location, or wherein a disc is unloaded from an optical disc drive but cannot be stored correctly because its assigned storage location is occupied by a second optical disc. One embodiment of the present invention provides a reconciliation process comprising a Robotics Server and a Datastor Service which collaborate in resolving ambiguities in optical disc identities and locations in a robotic optical disc jukebox or other physical storage system. The Robotics Server communicates directly with optical disc hardware, such as a robotic optical disc jukebox, which is capable of indicating whether storage locations (for either optical discs, or magazines capable of holding multiple optical discs) are occupied or unoccupied. The Datastor Service performs indexing, read, and write operations on database tables of an optical disc library. Other services, such as the Robotics Server, Title Server and Magazine Server communicate with the Datastor Service to request various data transactions to the various database tables in the optical disc library management system. Among the data stored in these tables are the associations between identified media and the physical locations to which the media have been assigned (e.g., an association between an identified optical disc and a particular tray of a particular optical disc magazine). To maintain high integrity and reliability of the optical disc management system, a reconciliation and synchronization process is preferably performed each time a user accesses magazine information or optical disc information. The reconciliation and synchronization process is performed, for example, to render a user's screen representation of an optical disc library when the user issues a command to show the contents of a magazine or an optical disc. Thus, the reconciliation process is activated not only when optical discs are believed misplaced, but also whenever any optical disc or magazine is accessed, such as when a user adds one or more optical discs to a magazine. Accordingly, the present invention advantageously provides early detection of any inconsistency between expected locations of optical discs and actual locations of optical discs. Not only does the reconciliation process of the present invention detect inconsistencies, but also it facilitates their resolution. FIGS. 12A, 12B, and 12C comprise a flowchart illustrating the steps performed to reconcile and synchronize assigned or expected disc locations with actual disc locations. In a first step 1202 (FIG. 12A), a user operating client software requests information about a selected magazine (or other holding unit) which the client software expects to exist in a particular storage location (or magazine bay). In a second step 1204 (FIG. 12B), the Robotics Server determines the status (occupied or not occupied) of the location in a robotic optical disc jukebox in which the client software expects the magazine to reside. If, in a next step 1206, the location is found to be empty (unoccupied), then in a step 1232 (FIG. 12C) the Datastor service determines whether any magazine is assigned to the location in the database. This is accomplished by searching records in a magazine database table for the location identifier (e.g., jukebox identifier and magazine bay index). If, in a step 1234, there is no magazine assigned to the location (i.e., the location identifier is not associated with any magazine) then the Datastor Service and the Robotics Server are synchronized (i.e., the magazine database does not expect a magazine in the location and no magazine occupies the location) and the synchronization steps terminate in a step 1236. If, however, in the step 1234, the Datastor Service determines that a magazine is erroneously assigned to the location (which, as determined by the robotics, is physically empty), the reference in the magazine database associating the location with a particular magazine is updated, in a step 1238, to indicate that no magazine is now assigned to the location. The optical disc management system maintains, in volatile computer memory, associations between magazine identification information and magazine location (i.e., in-memory images of locations). These in-memory images of magazine locations track which magazines are in which locations (e.g., which magazines are assigned to which bays of an optical disc jukebox). In a step 1240, the Robotics Server determines whether, in volatile memory, a magazine is associated with the location, and, if not, no further synchronization is necessary, and, in a step 1242, updated magazine location information is transmitted (or posted) to a client event queue. The client software retrieves and interprets the event and updates user displays accordingly. If, in the step 1240, the computer memory shows a magazine assigned to the location, then, in a step 1244, the volatile computer memory is altered to indicate that no magazine is assigned to the location, and, in a next step 1246 updated magazine location information is transmitted (or posted) to the client event queue. When, in the step 1206, there is a magazine in the location in which a magazine is expected, the Robotics Server, in a step 1208 determines an identity of the magazine by issuing a command to a robotic optical disc jukebox to cause it to examine a physical indicator (e.g., a bar code affixed to a magazine) which uniquely identifies each magazine in the optical disc management system. In a next step 1210, the Robotics Server determines whether a unique magazine indicator was successfully read, and, if so, the Datastor Service, in a step 1212, uses the value of the unique magazine indicator as a search key and searches records of the magazine database to determine whether the magazine database holds any information about the identified magazine. If one or more records in the magazine database hold references to the unique magazine indicator, then in a step 1214, the Datastor Service determines whether the magazine database holds an association indicating that the identified magazine is assigned to the location (e.g., determines whether the identified magazine occupies a location already assigned to it). If the identified magazine is assigned to the location, no further synchronization is necessary, and, in a step 1216, the synchronization steps terminate. If, in the step 1214, the identified magazine is mapped to a location different than the one in which it physically resides, then, in a step 1218, the magazine database is altered so that any magazines also mapped to that location are mapped to no location (i.e., NULL). In a next step 1220, the magazine database is altered such that the identified magazine is assigned to the location in which it was found. Next, in a step 1222, the in-memory image of the location is updated to indicate that the identified magazine is assigned to the location, and, in a step 1224, an event is posted to the client event queue indicating that the identified magazine has been assigned to the location. If, in the step 1212, the magazine database does not have a reference to the identified magazine, then, in a step 1226, a new record is added to the magazine database. The steps of 1218-1224 are then repeated to ensure the referential integrity of the database and to update the in-memory image of magazine locations. If, in the step 1210, the physical indicator (e.g., magazine barcode) uniquely identifying the magazine was not successfully read, then, in a step 1228, new information is added to volatile memory indicating that the magazine is identified as "untitled." The steps 1222 and 1224 for ensuring the referential integrity of the database and updating the in-memory image of the location are then carried out. The above steps, while relating to synchronizing actual and expected locations of optical disc magazines, also are useful to synchronize actual and expected locations of optical discs. Thus, when a client requests information from an optical disc expected to reside in a particular location, the above steps can be performed to ensure that the actual location of an optical disc matches the expected location of the optical disc. Although in general the steps to synchronize optical disc locations are similar to the steps to synchronize magazine locations, the detailed actions of some steps differ. To synchronize the location of an optical disc, step 1204 checks whether a particular tray expected to hold the optical disc is occupied or not. The step 1208 reads the FID (described elsewhere herein) of an optical disc, rather than the bar code of a magazine (although, in a preferred embodiment, this step is not performed in relation to optical discs due to performance considerations). Further, the optical disc title database (rather than the magazine database) is searched to determine expected locations of optical discs. One skilled in the art will appreciate that steps 1212-1228, rather than accessing a magazine database for associations with locations (bays), can be performed alternatively, in the case of synchronizing optical discs, by accessing an optical disc database for associations between optical discs and magazine (or optical disc drive) trays. It will further be appreciated with respect to steps 1228 and 1222 that, whereas magazine synchronization may require modifications to the in-memory image of magazine bay locations and their contents, synchronizing optical discs may require modifications to in-memory representations of disc storage trays and their contents. Those of ordinary skill will also understand that the differences just described with respect to the steps 1212-1228 also apply to the steps 1232-1244 in the case of synchronizing the locations of optical discs rather than magazines. The steps 1204-1228 and 1232-1244 are also used in the present invention to validate requests by client software to identify magazines or optical discs in selected locations. For example, when a user issues a command to reassign an optical disc in a third tray of a magazine to an eighth tray of the magazine, the corresponding steps to accomplish the user's request include the reconciliation and synchronization process (in this case performed with respect to the status of both the third tray which is expected to hold an optical disc, and to the eighth tray which may be expected to be empty). As another example, when a user issues a command to associate a different title (a user-selected textual name) with an optical disc, the reconciliation and synchronization process ensures that the expected disc occupies the expected location before the new title is associated with the optical disc. It will be appreciated that many combinations of moving the locations of optical discs and magazines exist, and also that reconciliation and synchronization steps will be included to validate such moves as well as to validate changes to identities of optical discs or magazines. In addition to automatically checking and recording the location of optical disc magazines and individual optical discs, an optical disc management system embodying the present invention allows users to manually assign the location of optical disc magazines and individual optical discs. When required, a user can remove an optical disc magazine from an optical disc jukebox and issue a request to reassign the location of that magazine, indicating that it no longer resides in an optical disc jukebox. A user may also remove an optical disc from a magazine and issue a request to reassign the location of that optical disc in the library. Alternatively, a user may introduce a magazine into an available bay of a jukebox and issue a request for the system to assign that bay location to the introduced magazine. Likewise, a user can introduce an optical disc into a magazine occupying a bay in a jukebox and issue a request to assign that new location to the newly introduced optical disc. FIG. 13 is a flowchart illustrating the steps involved in manually assigning a magazine location. In a first step 1302, a user places an optical disc magazine in a bay of an optical disc jukebox. In the next step 1304, the user issues a request to assign the introduced magazine to the bay of the jukebox in which the magazine was placed. In a step 1306, the present invention determines whether there is a magazine in that bay. If not, then in a step 1308, the system reports an error condition, indicating an attempt to assign a magazine to a location in which there is no magazine. The process then terminates in a step 1310 without having assigned any locations to the magazine identified by the user. If, in the step 1306, it is determined that there is a magazine in the bay identified by the user, the system then determines in a step 1312 whether a barcode on the magazine is readable by a barcode reader located in the jukebox holding the magazine. If the barcode cannot be read, then in a step 1314, the location of the optical disc magazine in the database is updated to indicate that the magazine resides in the bay selected by the user. The process then terminates in the step 1310. If, however, in the step 1312, the barcode on the magazine is readable, then, in a next step 1316, it is determined whether the barcode read from the magazine matches a known barcode for the magazine identified by the user. If the two barcodes match, then the database is updated in the step 1314, and the process terminates in the step 1310. If the barcodes do not match, then in a step 1318, an error report is generated describing the error condition of attempting to assign to the selected magazine a location that contains a different magazine. The process then ends in the step 1310. A distinct advantage of the present invention is that it permits an optical disc magazine to be represented in a magazine database even though the magazine does not occupy a physical bay of an optical disc jukebox. Therefore, there is no maximum number of magazines that can be represented in a magazine database. A graphical user interface presents to users a catalog including any number of optical disc magazines which comprise the off-line magazine shelf. The magazine shelf is represented by a single icon. By clicking and expanding on the magazine shelf icon, the graphical user interface presents the hierarchical display of each magazine in the off-line magazine shelf. By next clicking on any of the magazines exposed, the system will then graphically depict each of the optical discs stored in the magazine. Next, by clicking on any of the icons representing each of the optical discs in an exposed magazine, the system displays to the user the hierarchical list of all of the files and subdirectories located on an optical disc. Thus, in the case where an optical disc library contains a very large number of optical discs far exceeding the physical capacity of all optical disc jukeboxes on a network, the off-line magazine shelf extends the capacity of the optical disc library by making available to users an arbitrarily large index of the contents of all of the optical discs in the library, whether on-line or off-line. FIG. 14 illustrates the steps of removing a magazine from an optical disc jukebox and associating it with an off-line magazine shelf. In a first step 1402, a user removes an optical disc magazine from an optical disc jukebox. In a next step 1404, the user issues a request to assign the removed magazine to the off-line magazine shelf. The request issued in the step 1404 is preferably performed by a user clicking on an icon representing the magazine removed from the jukebox. Each magazine in each optical disc jukebox is uniquely identified by a magazine UID. The graphical user interface illustrates icons representing each magazine located in an optical disc jukebox. Thus, each icon representing a magazine also represents a magazine UID. In a step 1406, it is determined whether there is a magazine in the bay of an optical disc jukebox from which the user removed the magazine in the step 1402. If the bay is empty, then in a step 1408 the location of the removed magazine is updated by indicating in the magazine database that the magazine is now off-line (i.e., the magazine is now part of the off-line magazine shelf). The process then terminates in a step 1410. If, however, in the step 1406, it is determined that a magazine occupies the bay (from which the user supposedly removed the magazine), then, in a step 1412, it is determined whether the barcode of the magazine in the bay is readable. If the barcode of the magazine in the bay is not readable, then the step 1408 is performed to update the location of the magazine requested to be assigned to the off-line magazine shelf. The process terminates in the step 1410. If in the step 1412 the barcode is determined to be readable, then in a next step 1414, it is determined whether the barcode of the magazine in the bay matches the barcode associated with the magazine identified by the user in the request to assign a magazine to off-line status. If the barcodes do not match, then the steps 1408 and 1410 are performed. If the barcodes do match, then in the step 1416, an error report is generated indicating an attempt to assign to off-line status a magazine that currently resides in a bay of a jukebox. The system then terminates in the step 1410. FIG. 15 illustrates the steps of manually assigning a storage location to a selected optical disc. In a first step 1502, the user places an optical disc in a magazine. In a next step 1504, the user selects the newly loaded optical disc and issues a request to assign a specific location to the selected optical disc. Then, in a step | ||||||