a2) United States Patent
`US 6,195,650 B1
`(10) Patent No.:
`Gaitheret al.
`(45) Date of Patent:
`Feb. 27, 2001
`
`
`US006195650B1
`
`9/1998 Melo w.cecsecssecsessserernessees 709/232
`
`*
`
`5,802,397 *
`cited b
`.
`cuted’
`Dy examiner
`arineryTxaminer—iwomas©. Brick
`eaeeee ae
`(74) Attorney, Agent, or Firm—David A.Plettner
`(57)
`ABSTRACT
`
`(54) METHOD AND APPARATUS FOR
`VIRTUALIZING FILE ACCESS OPERATIONS
`AND OTHER I/O OPERATIONS
`Inventors: Blaine D. Gaither; Bret A. McKee;
`Gregory W. Thelen,all of Fort Collins,
`CO (US)
`
`(75)
`
`(73) Assignee: Hewlett-Packard Company, Palo Alto,
`CA (US)
`
`(*) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(21) Appl. No.: 09/498,798
`
`A method and apparatus virtualizes file access operations
`and other I/O operations in operating systems by performing
`string substitutions upon a file paths or other resource
`identifiers to convert the virtual destination of an I/O opera-
`tion to a physical destination. In accordance with the present
`invention, a virtual file system translation driver is inter-
`posed between a file system driver and applications and
`system utilities. The virtual file system translation driver
`receives file access requests from the applications and
`Feb. 2, 2000
`Filed:
`(22)
`—_-S¥Stem utilities, andtranslates the file path to virtualize the
`(51) UM. C17 cacssssssssnsnssneisininieentsee GO6F 12/09
`file system. In a first embodiment,thefile system is partially
`52)
`US. CI
`7/1; 1707/1, 707/2; 707/10:
`(52)
`US. 707/101.707/200: 707 04: 707/206: HL 4 virtualized and a user can see both the virtual file paths and
`1200;
`/204,
`7112B: 709)100
`the physicalfile paths. In second and third embodiments,the
`/101,
`_
`.
`;
`file system is completely virtualized from the point of view
`(58) Field of Search occas 707/1, 205, 2,
`of the applications and system utilities.
`In the second
`707/10, 101, 200, 204, 103, 206; 711/117,
`embodiment, a user may start with a physical file system,
`120, 6, 114, 3, 102, 103, 147, 202; 370/395,
`and virtualize the file system by installing the virtual file
`399; 709/203, 236, 310, 100, 227, 321
`system translation driver. When the driver is initially
`References Cited
`installed, all virtual file paths will be considered to translate
`to identically named physical file paths by default. In the
`U.S. PATENT DOCUMENTS
`third embodiment, virtual
`translations are automatically
`generated for all file paths when files and directories are
`created, and virtual
`file paths may bear limited, or no
`Sembine1 pyle pals
`
`(56)
`
`5,088,026 :
`2/1992 Bozman et al.cececceeeteee 711/3
`
`SUBSE > 2lom2 Talalons ROAM
`
`5,603,003 *
`2/1997 Akizawaetal. ...
` TIASLL4
`5/1998 Lucovsky et al. oe TLQ/6
`5,758,184 *
`
`
`1 Claim, 7 Drawing Sheets
`
`APPLICATIONS AND
`SYSTEM UTILITIES
`
`*
`
`12
`
`KERNEL MODE
`
`
` USER MODE
`
`
`
`VO SYSTEM SERVICES ee
`
`22—|
`
` t
`
`
`
`
`“| COMBINEDVIRTUAL|
`FILE SYSTEM DRIVER!
`VIRTUAL FILE SYSTEM
`TRANSLATION DRIVER
`
`
`FILE SYSTEM
`DRIVER
`
`
`
`NETWORK
`
`
`
`
`
`vo
`MANAGER
`
`
`
`
`NETWORK|29
`PROTOCOL
`STACK
`
`
`t 33
`NETWORK
`PORT
`
`
`
`
`
`HARDWARE ABSTRACATION LAYER
`
`
`24—
`
`ae
`
`CPU, ADAPTER, AND CONTROLLER HARDWARE
`
`Google Exhibit 1056
`Google v. VirtaMove
`
`Google Exhibit 1056
`Google v. VirtaMove
`
`

`

`U.S. Patent
`
`Feb. 27, 2001
`
`Sheet 1 of 7
`
`US6,195,650 B1
`
`
`
`
`
`APPLICATIONS AND
`SYSTEM UTILITIES
`
`16
`
`
`
`*NN.
`
`12
`
`USER MODE
`
`18
`
`34
`
`FAT16
`
`NETWORK
`
`
`
`
`KERNEL MODE
`
`14
`
`“x a
`
`/O SYSTEM SERVICES
`
`
`FILE SYSTEM
`
`
`DRIVER
`
`
`NTFS [26 37—LNETWORK|
`
`
`
`
`DISK CLASS
`DRIVER
`20
`NETWORK|29
`PROTOCOL
`STACK
`
`NETWORK
`PORT
`
`
`
`
`
`291
`HARDWARE ABSTRACATION LAYER
`
`
`CPU, ADAPTER, AND CONTROLLER HARDWARE
`
`24—
`
`wa
`
`10
`
`FIG. 1
`(PRIOR ART)
`
`

`

`U.S. Patent
`
`Feb. 27, 2001
`
`Sheet 2 of 7
`
`US6,195,650 B1
`
`APPLICATIONS AND
`SYSTEM UTILITIES
`
`XY
`
`
`
`KERNEL MODE
`
`18
`
`14
`
`COMBINED VIRTUAL!
`
`(0 SYSTEM SERVICES | “”
`FILE SYSTEM DRIVER!
`
`VIRTUAL FILE SYSTEM
`
`TRANSLATION DRIVER
`
`||
`
`||{
`
`;
`h—42 |
`I~ 44
`
` r™
`
`
`
`
`
`;
`h—~26 |
`
`||||
`
`FILE SYSTEM
`DRIVER
`
`
`DISK CLASS
`20
`DRIVER
`NETWORK|29
`38
`
`PROTOCOL
`
`SCsl
`STACK
`
`IDE
`PORT
`
`Sscsl
`PORT
`
`NETWORK
`PORT
`
`22
`
`24
`7ag
`
`HARDWARE ABSTRACATION LAYER
`
`CPU, ADAPTER, AND CONTROLLER HARDWARE
`
`FIG. 2
`
`

`

`U.S. Patent
`
`Feb. 27, 2001
`
`Sheet 3 of 7
`
`US 6,195,650 BI
`
`FROM APPLICATIONS
`AND SYSTEM UTILITIES
`16
`
`(oanoe
`___*
`
`J) START)
`
`48
`
`FROM FILE SYSTEM
`DRIVER 26
`—,
`------ »{ START
`
`mm N
`RECEIVE PHYSICALFILE
`
`PATH FROM FILE SYSTEM
`DRIVER 26
`
`
`|
`
`- <
`
`©
`
`—
`
`ON 66
`_ DOESA \(_
`S
`BACKWARD No
`TRANSLATION EXIST >
`“FOR THE PHYSICAL.“
`FILE PATH?~~
`me
`.
`_— a
`
`|
`
`eS
`RETRIEVE VIRTUALFILE
`PATH FROM "PENDING
`REQUEST" TABLE,
`_ TRANSLATE PHYSICALFILE |
`|
`PATH INTO VIRTUALFILE
`_PATH
`
`SEND VIRTUAL PATH TO
`APPLICATIONS AND SYSTEM +
`UTILITIES 16
`
`
`
`
`
` 50
`
`RECEIVE VIRTUAL FILE PATH
`FROM APPLICATIONS AND
`SYSTEM UTILITIES 16
`
`ao
`
` x
`
`—
`~ DOESA ™
`FORWARD ™\.
`a
`< TRANSLATION Exist NO
`||
`“FOR THE VIRTUAL ~~
`oSFILE PATH?
`aa“
`
`52
`
`YES
`
`
`TRANSLATE VIRTUAL FILE
`PATH INTO PHYSICAL FILE
`PATH, SAVE VIRTUAL AND
`PHYSICAL FILE PATHS IN
`
` |
`
`54
`
` "PENDING REQUEST" TABLE|
`
`
`SEND PHYSICAL PATH TO
`SJ FILE SYSTEM DRIVER 26
`
`56
`
`[
`
`TO FILE SYSTEM
`DRIVER 26
`
`TO APPLICATIONS AND
`SYSTEM UTILITIES 16
`
`FIG. 3
`
`

`

`U.S. Patent
`
`Feb. 27, 2001
`
`Sheet 4 of 7
`
`US6,195,650 B1
`
`FROM APPLICATIONS AND SYSTEM UTILITIES 16
`
`START
`
`74
`
`
`RECEIVE VIRTUAL FILE PATH
`FROM APPLICATIONS AND
`SYSTEM UTILITIES 16
`
`75
`
`a
`
`oN
`_- DOESA —
`“YES GO TO BLOCK 54
`FORWARD
`TRANSLATION EXIST > IN FIG. 3
`FOR THE VIRTUAL
`FILE PATH?-
`a
`a“
`
`76
`
`NO
`
`“4
`
`4
`DOES THE ™
`VIRTUAL FILE PATH
`a ALREADY EXIST AS A
`NN
`C PHYSICAL FILE PATHIN ~~
`78
`ANEXISTING
`_~
`TRANSLATION?“
`
`a
`
`YES
`
`NO
`
`GO TO BLOCK 56
`IN FIG. 3
`
`—*
`
`
`|
`~
`~~
`|GENERATE A NEW PHYSICAL
`oN
`Ze
`
`FILE PATH NAME AND
`IS THE FILE
`
`ACCESS REQUEST A YES|CREATE A TRANSLATION TO
`"CREATION"
`80
`TRANSLATE THE VIRTUAL
`
`
`REQUEST?_~
`FILE PATH TO THE NEW
`
`
`
`
`PHYSICAL FILE PATH
`
`~,
`
`NO
`
`RETURN A "FILE PATH NOT
`FOUND" MESSAGE TO
`APPLICATIONS AND SYSTEM
`UTILITIES 16
`
`
`
`Tt
`wa ( ENDya
`
`TO FILE SYSTEM DRIVER 26
`
`82
`
`42
`
`GO TO BLOCK 54
`IN FIG. 3
`
`FIG. 4
`
`

`

`U.S. Patent
`
`Feb. 27, 2001
`
`Sheet 5 of 7
`
`US 6,195,650 BI
`
`
`
`
`
`YAAYASNOILVISNVYL
`
`
`
`LNAWS9VNVYWNOLLVISNVaL
`
`
`
`NOILVOINddVNOILVYLSININGY
`
`NOILVLSHYOM
`
`
`
`WALSASA1ldTWALYIA
`
`
`
`Y3AlWdNOILVISNVYL
`
`SY¥asnCNV
`
`AGOW1SNYA4y
`
`AGOWY¥ASN
`
`colv6
`
`
`AaSVaEvVLvVdNOILVISNVYLGANIS30
`
`
`‘SNOILVOMddvV‘SWALSAS‘SALIS
`
`
`YOdSNOILVISNVYLSSAYOLS
`
`YOLVYLSININGVYHHOMLAN
`96 cv
`
`GANIAS0YOLVELSININGV
`
`ASvVaVLVdNOILVISNVYL
`
`c6
`
`S$‘Sid
`
`
`
`Q3NI43GYASN/1V907
`
`SNOILVISNVYL
`
`
`
`MYOMLANGSHOVO
`
`SNOILVISNVYL
`
`
`
`
`

`

`U.S. Patent
`
`Feb. 27, 2001
`
`Sheet 6 of 7
`
`US6,195,650 B1
`
`PHYSICAL FILE
`PATH OR NO
`TRANSLATION FOUND
`
`TRANSLATION DATABASE
`
`MANDATORY CACHED NETWORK ADMINISTRATOR
`DEFINED SITE TRANSLATIONS
`
`
`
`
`
`
`
`MANDATORY CACHED NETWORK ADMINISTRATOR
`DEFINED SYSTEM TRANSLATIONS
`
`
`
`MANDATORY CACHED NETWORK ADMINISTRATOR
`DEFINED APPLICATION TRANSLATIONS
`
`MANDATORY CACHED NETWORK ADMINISTRATOR
`DEFINED USER TRANSLATIONS
`
`PREFERRED CACHED NETWORK ADMINISTRATOR
`DEFINED SYSTEM TRANSLATIONS
`
`PREFERRED CACHED NETWORK ADMINISTRATOR
`DEFINED SITE TRANSLATIONS
`
`FIG. 6
`
`96
`
`
`
`
`
`
`
`MANDATORYLOCAL/USER DEFINED SYSTEM
`
`
`TRANSLATIONS
`MANDATORY LOCAL/USER DEFINED APPLICATION
`TRANSLATIONS
`
`MANDATORY LOCAL/USER DEFINED USER
`TRANSLATIONS
`
`
`"
`99
`
`PREFERRED LOCAL/USER DEFINED USER
`TRANSLATIONS
`
`
`
`
`PREFERRED LOCAL/USER DEFINED APPLICATION
`
`
`TRANSLATIONS
`
`
`PREFERRED LOCAL/USER DEFINED SYSTEM
`TRANSLATIONS
`
`PREFERRED CACHED NETWORK ADMINISTRATOR
`DEFINED USER TRANSLATIONS
`
`
`
`PREFERRED CACHED NETWORK ADMINISTRATOR
`DEFINED APPLICATION TRANSLATIONS
`
`
`
`
`|\_
`
`x
`
`HIGHER
`PRIORITY
`
`LOWER
`PRIORITY
`
`
`
`
`
`
`VIRTUAL
`FILE
`PATH
`
`

`

`U.S. Patent
`
`Feb. 27, 2001
`
`Sheet 7 of 7
`
`US 6,195,650 BI
`
`YOHLVdAldTWOISAHd
`
`NOILVISNVYLON
`
`GANISAG
`
`<
`
`SAHOVO
`
`Z°Sldey
`
`
`UHNOILVISNVY_LGASVdLIHslSHOVO
`
`
`
`
`“AldGNVdasvaNOLLVISNVYLGASVdSHOVD
`
`
`
`“AMOWAWAlvddn“AYOWAWsalvdadn
`
`
`
`NOILVISNVdLlGAasSva
`
`96ASVAEVLVG
`
`AHOVONOILVISNVaLL
`
`-AYOWAWHOYVAS
`
`
`HOYVAS\80\901r0l
`
`
`
`
`ASYSAVEL
`
`NOILVISNVYL
`gasva-sals
`
`TWOLYlA
`
`
`
`
`
`
`

`

`US 6,195,650 B1
`
`1
`METHOD AND APPARATUS FOR
`VIRTUALIZING FILE ACCESS OPERATIONS
`AND OTHER I/O OPERATIONS
`FIELD OF THE INVENTION
`
`The present invention is a method and apparatus for
`virtualizing file access operations and otherI/O operations in
`operating systems. More specifically, the present invention
`virtualizes file access operations and other I/O operations by
`performing string substitutions upon file paths or other
`resource identifiers to convert the virtual destination of an
`operation to a physical destination.
`DESCRIPTION OF THE RELATED ART
`
`10
`
`2
`There are a number of mechanisms knownin theartthat
`can virtualize file system access operations to a limited
`extent. For example, in the Windows NT® or Windows® 98
`operating system, a global variable called “Temp” is typi-
`cally defined that allowsall programs to access a common
`temporary directory. By changing the file path contained in
`the variable, the location of the temporarydirectory used by
`all programs can also be changed.
`Two other mechanisms common in Unix® operating
`systems are symbolic links and hard links. Unix® is a
`trademark of the Open Group.
`In the Unix® operating
`system, each file and directory location is defined by an
`“jonode” number, and the file system directory maintains
`mappings between file and directory names and ionode
`numbers. A hard link is simply a second mapping between
`a file or directory name and an ionode numberthat has
`already been mappedto a first name. The file or directory is
`not actually deleted until all file and directory names that
`map to the ionode number have been deleted. Hard links
`must reference files and directories on the samefile system,
`are transparent to the application, and cannot be used to
`arbitrarily re-map between partitions or devices because the
`ionode numbersonlyrefer to files and directories within the
`file system.
`In contrast, a symbolic link is a separate file with its own
`ionode number. The symbolic link contains a text string that
`points to another file or directory. Accordingly, symbolic
`links can be used to reference files and directories in
`
`volume, the user only sees directories and files beneath the
`mounting point, and doesnot see the directories of the other
`users. Mount points are transparent to applications and can
`be re-mapped arbitrarily, but do not provide file level
`granularity and do not re-map directories underneath the
`mount point.
`Finally, some enterprise storage subsystems have the
`ability to move a user’s file system from one hard drive to
`another. Such moves can be performed arbitrarily and are
`transparent to applications, but do not provide file or direc-
`tory level granularity.
`Taken individually, none of these mechanisms provides a
`meansto arbitrarily re-map files and directories at any level
`and between any file system in a mannerthat is transparent
`to applications. In csscnec, none of these mechanisms is
`capable of providing applications with a “virtual view” of
`the file system. What is neededin the art is a mechanism that
`can arbitrarily re-map files and dircctorics at any level and
`between any file system in a mannerthat is transparent to
`applications.
`In essence, what
`is needed in the art
`is a
`mechanism capable of completcly virtualizing an applica-
`
`In the art of computing, an operating system is typically
`used to provide access to the resources of a computer
`system. One important
`type of resource that must be
`accessedis the file system. Typically, a file system provides
`access to files on a local hard drive, as well as files that may
`reside on a networkserver, which is coupled to the computer
`system via a network.
`One trend that has been important to the evolution of
`computing is to virtualize resources, thereby provided a
`computer program with a virtualized version of a resource
`and making the actual (or physical) attributes of a resource
`invisible to the program. For example, virtual memory
`systems, which are well knownin the art, provide a com-
`puter program with the illusion that the program can access
`a large contiguous area of memory, which is knowninthe art
`different file systems. Symbolic links are not transparent to
`as virtual memory. The operating system managestransla-
`the application, since the application can detect that it is
`tions between virtual memory and physical memory. Con-
`accessing a link and not
`the actual
`file or directory.
`tiguous regions of virtual memory may be mapped to
`Furthermore, deleting a symbolic link deletes the link, not
`non-contiguous regions of physical memory, and portions of
`the file or directory. Like hard links, symbolic links translate
`virtual memory maybe stored in a swap file on a hard disk
`a single file or directory from one location to another.
`drive of the computer system. This allows the computer
`However, symbolic links maybe arbitrarily re-mapped from
`system to execute programs requiring more memorythan is
`one file system to another.
`physically available in the computer system, and allows
`Mount points can also virtualize file systems to some
`multiple programs to be active simultaneously. Other
`extent. A mount point simply allows a drive volume to be
`examples of vitalized resources include multiple CPUs, and
`40
`mounted at some point within an existing directory tree
`multiple windows in a windowed operating system.
`structure. For example, assume that a hard drive onafile
`Despite the trend toward virtualizing computer system
`sever has a root directory, and under the root directory are a
`resources, file systems tend to have very limited virtualiza-
`series of directories, with each directory identified by the
`tion features. Typically, once the physical location of a hard
`initials of the user that uses that directory. When a user logs
`drive, and the directory structure and files contain thereon,
`in, a drive volumeis mountedat the directory corresponding
`has been defined, a computer program is locked into this
`to the users initials. When the user accesses that drive
`structure. Kor example, consider a simple example faced by
`many computer users using the Windows NT® or Win-
`dows® 98 opcrating system which are products of
`Microsoft® Corporation. A computer user purchases a com-
`puter system with a single hard drive that is referenced as
`“c:\". Over time,
`the user fills up the hard drive, and
`therefore adds a second hard drive that will typically be
`referenced as “d:\”. To recover space on the original “c:\”
`drive, the user may wish for example, to move the contents
`of the directory “c:\Program Files” to “d:\Program Files”.
`However, doing so causes many problems. For example, all
`the shortcuts for accessing programs from the start menu
`still refer to the “c:\” drive, so the user will no longerbe able
`to launch the programs. Furthermore, the registry contains
`numerous references to the programs that were previously
`stored on the “c:\” drive. Typically, the uscr must reinstall all
`the applications that are to be moved to the “d:\” drive, or
`purchase and execute a third party utility that attempts to
`find every reference to the moved applications in shortcuts,
`the registry, or any other place where a reference may be
`located, and alter those references. Both processes are
`cumbersome, and may not be completely effective
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`

`3
`tion’s view of the file system, just as a virtual memory
`system virtualizes an application’s view of a physical
`memory system.
`
`4
`from applications and system utilities in accordance with a
`second embodimentof the invention.
`FIG. 5 shows a workstation and a translation server
`
`US 6,195,650 B1
`
`SUMMARYOF THE INVENTION
`
`coupled together by a network,andillustrates how a network
`administrator can manage translations in accordance with
`the present invention.
`The present invention provides a method and apparatus
`FIG. 6 is a block diagram illustrating a prioritization
`for virtualizing file access operations and other I/O opera-
`scheme that manages translations in accordance with an
`tions in operating systems by performingstring substitutions
`embodiment of the present invention.
`10
`uponafile paths or other resource identifiers to convert the
`FIG. 7 is a block diagram illustrating memory-based and
`virtual destination of an I/O operation to a physical desti-
`file-based translation caches for use with the virtual file
`nation. In accordance with the present invention, a virtual
`system translation driver of FIG. 2.
`file system translation driver is interposed betweenafile
`system driver and applications and system utilities. The
`DETAILED DESCRIPTION OF THE
`virtual file system translation driver receives file access
`PREFERRED EMBODIMENTS
`requests from the applications and system utilities, and
`The present invention provides a method and apparatus
`translates the file path to virtualize the file system. The
`for virtualizing file access operations and other I/O opera-
`virtual file system translation driver can also be combined
`tions in operating systems by performingstring substitutions
`with the file system driver to create a combinedvirtualfile
`
`system driver. The present invention can be utilized on uponafile paths or other resource identifiers to convert the
`workstations, networkservers, and other computing devices.
`virtual destination of an operation to a physical destination.
`Before discussing the present invention in detail, first con-
`In a first embodiment of the invention, the file system is
`sider a typical prior art computer system that uses the
`partially virtualized and a user can see both the virtual file
`Windows NT® operating system, which is a product of
`paths and the physical file paths. In this embodiment, the
`Microsoft® Corporation. Those skilled in the art will under-
`virtual file path is translated to a physical file path if a
`stand howto apply the concepts discussed herein to other
`translation exists, and the file access operation is processed
`operating systems, such as Unix®. Unix® is a trademark of
`using, the physical file path. If no translation exists, the file
`the Open Group.
`path provided by the application orutility is used to process
`FIG. 1 showsa prior art computer system 10. Only those
`the file access request.
`portions of computer system 10 that are required to under-
`In second and third embodiments ofthe present invention,
`stand the file system are shown in FIG. 1. The operating
`the file system is completely virtualized from the point of
`system executes instructions in user mode 12 and kernel
`view of the applications and system utilities. In the second
`mode 14. Typically, applications and system utilitics 16 are
`embodiment, a user may start with a physical file system,
`executed in user mode 12, and I/O system services 18 are
`and virtualize the file system by installing the virtual file
`executed in kernel mode 14.
`system translation driver. When the driver
`is initially
`installed, all virtual file paths will be consideredto translate
`to identically named physical file paths by default. In the
`third embodiment, virtual
`translations are automatically
`generated for all file paths when files and directories are
`created, and virtual
`file paths may bear limited, or no
`resemblance to physicalfile paths.
`One of the disadvantages provided bypriorartfile system
`is that the attributes of a particular storage device apply
`globally to all files in the file system.
`In essence,
`the
`attributes of the storage device are “joined at the hip” with
`the file system installed on the storage device. The present
`invention breaks this connection. Accordingly, a user can
`view a single file system,yet files within that file system can
`be stored on storage devices having different attributes. The
`present invention provides many other advantages and may
`be implemented in several ways, as described in greater
`detail below.
`
`/O system services 18 represents all I/O functions of
`computer system 10. I/O system services 18 include an I/O
`manager 20, which manages I/O operations and will be
`discussed in greater detail below. CPU, adapter, and con-
`troller hardware block 24 represents the physical computing
`resources of computer system 10. Hardware abstraction
`layer 22 couples block 24 to I/O manager 20. The purpose
`of hardware abstraction layer 22 is to communicate with the
`resources represented by block 24 (which typically vary
`between different computer systems) and provide a uniform
`“abstracted” view of these resources to I/O manager 20.
`In FIG. 1, those portions of I/O manager 20 that manage
`accessto the file system are file system driver 26, disk class
`driver 28, network protocol slack 29, IDE port 30, SCSI port
`32, and network port 33. File system driver 26 receives file
`access requests from applications and system utilities 16.
`File system driver 26 determines whether a file access
`request is attempting to access a file on a local hard drive,
`or a networkeddrive. If the file access requestis attempting
`to access a local hard drive, the request is processed by FAT
`16 block 34 or NTFS block 36 based on the type of file
`system used on the partition that is the target of the request.
`The FAT 16 and NTFSfile systems are the most commonfile
`systems used on a Windows NT® workstation, but of
`course, other file systems are known in theart. If the file
`access requestis attempting to access a networked drive, the
`request is processed by network block 37.
`Assumethat the file access request is attempting to access
`a local hard drive. The request is translated to access the
`appropriate hard drive sectors based on the file system, and
`is passed to disk class driver 28. If the target of the request
`is a SCSI drive, SCSI block 38 handles the request. If the
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 showsportions of a prior art computer system that
`are required to understand a file system of the prior art
`computer.
`FIG. 2 shows a computer system having a virtual file
`system translation driver in accordance with the present
`invention.
`
`FIG. 3 is a flow chart showing how the virtual file system
`translation driver of FIG. 2 translates file requests from
`applications and system utilities in accordance with a first
`embodiment of the invention.
`FIG. 4 is a flow chart that illustrates how the virtual file
`
`system translation diver of FIG. 2 translates file requests
`
`55
`
`60
`
`65
`
`

`

`US 6,195,650 B1
`
`5
`target of the request is an IDE drive, IDE block 40 handles
`the request. While the SCSI and IDEinterfaces are the most
`common methads of connecting hard drives to computer
`system, other connection methods are known in the art.
`Thereafter, the request is passed to IDE port 30 or SCSI port
`32 (based on the hard drive interface type), and the request
`is completed by hardware abstraction layer 22, and CPU,
`adapter, and controller block 24. Theresults ofthe file access
`request then flow backupto applications and system utilities
`16.
`
`Returning to file system driver 26, now assumethat the
`file access request is attempting to access a networked drive.
`As mentioned above, such a requestis processed by network
`block 37. The request flows through network protocol stack
`29 and to network port 33, and the request is complete by
`hardware abstraction layer 22 and CPU, adapter, and con-
`troller block 24. The results of the file access request then
`flow back up to applications and system utilities 16. Note
`that manytypes of network protocols are knownin theart.
`For example, it is commonfor networked computer systems
`to communicate via the ‘I'CP/IP protocol over an Ethernet
`network.
`
`TIG. 2 shows computer system 46 having a virtual file
`system translation driver 42 in accordance with the present
`invention. Note that most of the other components of com-
`puter system 46 are similar to the corresponding components
`of computer system 10 of FIG. 1, and therefore have the
`same reference numerals as the corresponding components
`of computer system 10.
`Virtual file system translation driver 42 is interposed
`between file system driver 26 and applications and system
`utilities 16, and may be installed as a separate driver in
`Windows NT®. Virtual file system translation driver 42
`receives file access requests from applications and system
`utilities 16, and translates the file path to virtualize the file
`system. Note that computer system 46 also includes a dotted
`line box labeled combined virtual file system driver 44.
`Combined virtual file system driver 44 includes virtual file
`system translation driver 42 andfile system driver 26, and is
`included to show that drivers 42 and 26 can be combined
`
`into a single driver 44. While the discussion that follows will
`be primarily with reference to virtual file system translation
`driver 42, those skilled in the art will understand how to
`adapt the teachings contained herein to combine drivers 42
`and 26 to create combinedvirtual file system driver 44.
`There are many different embodiments and configurations
`of the present invention, which will be described below. The
`present invention can be used to provide complete or partial
`virtual translation. The present invention can allow indi-
`vidual files and directory paths to be virtualized based onsite
`requirements, system requirements, applications, users,
`processes, or any other variable, such as the time of day. The
`virtual
`translations can be defined by a local user or
`administrator, by a remote administrator, or can be generated
`automatically. The virtual translations can be defined by a
`network administrator and stored on a network drive, with a
`cached copyof the most recently received translations stored
`on a workstation to allow the workstation to function when
`not connected to a network. The virtual translations can also
`
`be defined as a hierarchythat includes preferred translations
`and mandatory translations. The present invention can also
`reside on a network server,
`thereby allowing networked
`drives to be virtualized on the server side. Finally,
`the
`present invention can be adapted to work with other types of
`I/O operations. For example, print requests can be
`virtualized, as will be described below.
`To illustrate a first embodiment of the present invention,
`consider an example similar to the onc discussed above in
`
`10
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`the “Description of the Related Art”. A computer user
`purchases a computer system with a single hard drive thatis
`referenced as “c:\”. Over time, the user fills up the bard
`drive, and therefore adds a second hard drive that will
`typically be referenced as “d:\”. ‘lo recover space on the
`original “c:\” drive,
`the user moves the contents of the
`directory “c:\Program Files” to “d:\Program Files’, and the
`contents of the directory “c:\My Documents” to “d:\My
`Documents”. As discussed above, simply moving the direc-
`tories will “break” the applications because shortcuts and
`registry entries will still point to the “c:\” drive.
`In this embodiment, assumethat translations are stored in
`a file called “vftranslate.ini”. More complex translation
`databases will be discussed below and would typically be
`used in other embodiments. For example, it maybe desirable
`to store translations in the registry. However,
`in this
`embodiment, assumethat the user either manually edits the
`file “vftranslate.ini” or uses a utility that managesthefile so
`that the file includes the following entries:
`
`Contents of “vftranslate.ini”
`
`c:\Program Files\*
`c:\My Documents\*
`
`d:\Program Files\*
`d:\My Documents\*
`
`Each line of the file “vftranslate.ini” contains a virtual
`
`translation. The first entry is is the virtual file path and the
`second entry is the physical file path to which the virtual
`path will be translated. Note that conventional wild card
`characters are used in the above example, with a “*” used to
`match any numberof characters following the string.
`TIG. 3 is a flow chart showing how vita file system
`translation driver 42 translates file requests from applica-
`tions and system utilities 16 in the first embodimentof the
`invention. Assume that a user attempts open a file called
`“c:\My Documents\letters\document.wpd” from a word pro-
`cessor program. In FIG. 2, the file access requestis sent from
`applications and system utilities 16 to virtual file system
`translation driver 42, Referring to FIG. 3, in a first phase of
`the file access request, driver 42 begins execution at “start”
`block 48, and receives the virtual
`file path “c:\My
`Documenis\letters\document.wpd” from applications and
`system utilities 16 at block 50.
`Decision block 52 determines whether a forward transla-
`
`tion exists for the virtual file path. If no virtual translation
`exists, then the virtual file path is equivalent to the physical
`file path, and the “NO”branchis taken to block 56, where
`the physical file path is sent onto file system driver 26 of
`FIG. 2. However, in this example the file “vftranslates.ini”
`contains a translation for “c:\My Documents\*”, so the
`“YES”branch is taken to block 54. Block 54 performs a
`string substitution upon the virtual path by replacing “c:\My
`Documents\” with “d:\My Documents”. Accordingly, the
`virtual
`file path is
`translated from “c:\My
`Documents\letters\document.wpd”to the physical file path
`“d:\My Documents\letters\document.wpd”. Block 54 also
`stores the virtual and physical file paths in a “pending
`request” table that allows the request to be uniquely iden-
`tified. The reason for storing the virtual and physical file
`paths in the pending request table will be described below.
`
`

`

`US 6,195,650 B1
`
`7
`Control then passes to block 56, where the physical file path
`is sent to file system driver 26, and execution of the first
`phase terminates at “end” block 58. At this point, the file
`access request is serviced by file system driver 26 and the
`other components shown in FIG. 2.
`After the file access request has been serviced, the results
`will flow back up to virtual file system translation driver 42
`from file system driver 26. This is represented in FIG. 3 by
`dotted line 60. Accordingly,
`the second phase of the file
`access request begins at “start” block 62. At block 64, the
`physical file path from file system driver 26 is received by
`virtual file system translation driver 42. Note that the physi-
`cal file path may be accompanied by an error message, such
`as “file d:\My Documents\letters\document.wpd not found”,
`or may be accompanied by an indication that the file has
`been opened and may be accessed. Whatever information
`flows between file system driver 26 and applications and
`system utilities 16 in FIG. 1 will flow through virtual file
`system translation driver 42 in FIG. 2, except that the path
`may betranslated.
`Next, decision block 66 determines whether a backward
`translation exists for the physical file path by accessing the
`pending request table. If there is no backward translation,
`the physicalfile path from file systemdriver 26 is equivalent
`to the virtual file path, the “NO”branchis taken to block 70,
`and the virtual file path is sent to applications and system
`utilities 16. [lowever,in this example a backwardtranslation
`exists so the “YES” branch is taken to block 68. Using the
`physical file path, block 68 retrieves the virtual file path
`from the pending request table and translates the physical
`file path back to the virtual file path. Accordingly,
`the
`physical
`file path is translated from “d:\My
`Documents\letters\document.wpd” back to the virtual file
`path “c:\My Documents\letters\document.wpd”. Control
`then passes to block 70 and the virtual file path is sent to
`applications and system utilities 70, along with all other
`information associated with the file access request. Finally,
`execution terminates at “end” block 72.
`
`One of the advantages provided by the present invention
`is that the process of re-mapping directories can be done
`on-the-fly without having to reboot
`the computer. For
`example, the directory tree of a program can be moved to
`another location, with the file “vftranslate.ini” updated by
`the computer user to reflect
`the new location, and the
`program can be immediately executed. Even though all
`shortcuts and registry entries point to the old physical file
`paths of the program, the present invention will virtualize
`the old file paths to the new physical file paths and the
`program will function normally.
`In the above example, there is a one-to-one correspon-
`dence between the virtual and physical
`file paths.
`Accordingly, the pending request table is not actually needed
`because it would be possible to resolve the physical file path
`back to the virtual file path by simply using the information
`contained in the file “vftranslate.ini”. However, while a
`virtual file path must alwaysresolveto a single physicalfile
`path going forward, a physical file path can resolve to
`multiple virtual file paths going backward.
`F