The present invention relates to computer systems, and more particularly, to techniques for controlling and distributing files within a computer system.
A file system is a subsystem that an operating system or program uses to organize and keep track of files. File systems may be organized in different ways. For example, a hierarchical file system is one that uses directories to organize files into a tree structure. File systems provide the ability to search for one or more files stored within the file system. Often this is performed using a “directory” scan or search. In some operating systems, the search can include file versions, file names, and/or file extensions.
Although the operating system provides its own file management system, third party file systems may be developed. These systems can interact smoothly with the operating system but provide more features, such as encryption, compression, file versioning, improved backup procedures, and stricter file protection. The determination as to which file system to use is performed within the operating system at the virtual file system (VFS) layer. The VFS layer provides an abstraction through which all operating system or application requests to file systems are passed. The VFS layer examines the request, and routes it to the appropriate file system for fulfillment. In some versions of Microsoft Windows, the VFS is called the “redirector”.
Some file systems are implemented over networks. Two common systems include the Network File System (NFS) and the Server Message Block (SMB, now CFIS) system. A file system implemented over a network takes a request from the operating system, converts the request into a network packet, transmits the packet to a remote server, and then processes the response. Other file systems are implemented as downloadable file systems, where the file system is packaged and delivered as a unit to the user. Examples of downloadable file systems include files for the well known application WinZip.
File systems share an abstracted interface upon which the user may perform operations. These operations include, but are not limited to:                Mount/Unmount        Directory scan        Open(Create)/Close        Read/Write        Status        
The steps of associating a file system with an operating system (e.g. making the Virtual Layer binding of the file system to the operating system) are collectively called “mounting”. In common usage, a newly mounted file system is associated with a specific location in a hierarchical file tree. All requests to that portion of the file tree are passed to the mounted file system. Different operating systems impose restrictions on the number and how deeply nested file system mounts can be. Un-mounting is the converse of mounting: a file system is disassociated from the operating system.
Once a file has been located, the user can request that the file be opened. This establishes a file in the file system, and updates the directories and attributes accordingly. It often returns a “handle” or “file number” to the caller for use in later I/O calls to the file system. Close is the converse of open, and releases the resources associated with the previously open file.
Read and write are self-explanatory. They are the basic I/O calls to a file in a file system.
Status returns the status of a file or a file system. It is used by applications that directly manipulate the files in a file system.
A journaled file system is one in which the hard disk maintains data integrity in the event of a system crash or if the system is otherwise halted abnormally. A journaled file system maintains a log, or journal, of what activity has taken place in the main data areas of the disk. If a crash occurs, any lost data can be recreated because updates to the metadata in directories and bit maps have been written to a serial log. A journaled file system not only returns the data to the pre-crash configuration but also recovers unsaved data and stores it in the location in which it would have been stored if the system had not been unexpectedly interrupted.
Some file system technologies, such as those provided with Digital Equipment Corporation's VMS operating system, provide the capability to track differing versions of files, often assigning them different version numbers. Higher-level concepts such as configuration management baselines and releases are constructed on top of files, but historically are not managed within the file system.
The above technologies are useful but are generally provided independently and without mechanism for centralized control. Those controls that are present are generally access control list (ACL) based and mediate basic access mechanisms like read and write. They do not govern more finely grained concepts such as journaling, file versioning, and the isolation of users.
In the past, applications stored on a file system were self-contained. An application software title (generally) consisted of one or more files that could be used only by the application software title. These files included data files, configuration files, and the application executable(s). Applications software titles would generally not interfere with each other.
The Windows operating environment takes advantage of a capability called dynamic linking to allow application software titles' code modules to be shared between different application software titles. The most important demonstration of the use of this capability is the common operating system, Microsoft Windows—the code modules that contain the functions that make Windows work (the Windows API), are shared by all Windows applications. A code module that can be shared in this way is commonly called a dynamic link library and normally has the extension .DLL. Other names and formats of shared libraries were also used, .VBX, .OCX, and numerous others. Use of shared modules is also supported by other common operating systems, such as Unix and Linux, as well as internally by many programming languages such as Perl or development environments such as Forte or the Rational RUP.
DLLs are sometimes installed in a directory with an application. At other times they are installed in “shared” directories. The search order for DLLs and shared libraries is controlled externally from the application using the PATH environment variable. Changing the PATH often changes the way an application executes.
It is not unusual for users to reinstall software, either during a system upgrade or to change configurations. In many cases users install software that included an older version of a DLL i.e. COMMDLG.DLL on a system that already contained a newer version. This causes the more recently installed version to replace the newer version. As soon as the user attempts to run the program that required the newer version, problems occur ranging from operational difficulties to application failures. Changes made to an application by one user may effect the operation of the application by a different user. Support and development personnel can literally spend hours trying to figure out what is wrong with a customer's machine, and why their applications will no longer run.
The component-solution framework for programming has made this problem worse. Instead of a few DLLs that are shared by several applications, there are hundreds of DLLs, VBXs and OCXs that may be shared by literally thousands of applications. All it takes is a single DLL, VBX or OCX to be missing, or present in an older version (or even an incompatible newer version), for an application to fail. A poorly designed installation program, user error, registration error or change in the user's PATH environment variable are a few of the ways in which this problem can occur.
In the same vein, applications that are uninstalled cannot determine if “shared” DLL's are required by other applications, and either remove the DLL's (causing other applications to stop working), or leave them to clutter the system and cause confusion and conflicts with later software installs.
Microsoft named this problem “DLL hell”, and revised their DLL naming and binding schemes, and incorporated these changes into their NET version of Windows to address these types of problems. The NET solutions do not isolate the changes made by one user from those from those seen by a different user, and for backward compatibility reasons, many of the old issues remain. Issues related to “DLL hell” is also present with managing the information that is shared between applications, including application and user configuration information, shared data files, and user-specific data files.
A particular problem exists with the management of data for users of applications that were originally designed for use by a single user, but are installed on a PC that supports more than one user, either simultaneously or sequentially. When this type of software is installed and used, they must first share installation information that may contain user specific information, such as the user's name and company, as well as personal preferences such as screen layout and the last window context that the user was in. Additionally, the user's information may be stored in files that are managed by the application. Such information may be sensitive in nature, such as personal information, such as that stored by a financial application such as TurboTax.
When a user installs and uses an application such as TurboTax, they provide personal information, including name, social security number, wage, and deduction information to the application to be stored in data files on the local file system. If a second user then tries to install and use TurboTax, the program files, configuration files, and data files of the first user are presented to the second user, who may not be related or permitted to view the first user's information. What is needed is a mechanism to separate the program, data, and configuration information of each user, without complex multi-user programming by each commercial software vendor.
A need exists to provide a system of on-demand delivery of content that permits users and processes to download and use application software titles in a self-contained manner that, automatically provides configuration management capabilities for these application software titles, and provides distributable policy-based controls over the downloading, use of the applications, contents, and structure of the application software titles. A further need is for these policies and downloadable content to be usable on the host PC without additional installation steps beyond the determination to download and run the application.
It is additionally desirable for the system to track changes made by users and processed, and to optionally isolate users and processes from each other under policy control.
It is further desirable that the name spaces between local, mounted, and downloadable file systems be integrated, either statically, or using by using centralized or distributed control methods. Name space integration provides a seamless view of the file system to the user.
It will be appreciated that improvements in the art described in the present disclosure that satisfy the above requirements will find use in many applications.
USPTO Backgrounds
USPTO Backgrounds