Browse Prior Art Database

A Virtual FileSystem (VFS) across multiple network nodes and disks Disclosure Number: IPCOM000014201D
Original Publication Date: 1999-Oct-01
Included in the Prior Art Database: 2003-Jun-19

Publishing Venue


Related People

Edd Doutre John Fluke


In a network of computers, there is often a need to extend some operating systems' file systems to accommodate file and directory names that are not supported natively. When implementing Java Virtual Machines (JVMs) on file systems that only support "8.3" names (up to 8 characters for the name and up to 3 characters for an extension or type) this becomes very apparent. An trivial example is: "SomeJavaApplication.class", which violates both the 8 character name and the 3 character extension limits. Special characters, DBCS (Double Byte Character Set), UpperCase and LowerCase letters, spaces within names and a host of other limitations can cause problems that limit the usefulness of an otherwise desirable file system. The author has implemented a Virtual File System (VFS) that allows clients to map many names that use these 'problem' characters and can far exceed the length of a file or directory name or total length of a 'path'. The VFS consists of a Name Space Server accessed via TCP/IP sockets (for now) and a run-time VFS Client. In essence the run-time client intercepts names that are allowed to exceed the limits of the native file system and sends them to the Name Space Server to be converted into names that are supported natively. The function of this VFS Name Space Server is analogous to that of a TCP/IP network Domain Name Server (DNS) or bind server which maps IP addresses and node names back and forth. However, the VFS Name Space Server is involved in many simultaneous operations performed by numerous applications and therefore has some severe performance requirements and also does not have the IP name restrictions that limit the total number of usable names. A typical DNS implementation also does not face the dynamic creation and deletion of names and the attendant management problems that entails. Some of these differences are readily apparent when given some examples: A typical DNS would map the IP node name "" to an IP address of (for example) and another IP node name with the same "" would only differ in the least significant number (the ".1" might be for instance become ".2"). These restrictions are documented in various Request For Comment documents (commonly known as RFC's) (e.g. RFC 1034/2535) and are tightly controlled because of their impact on IP routers, which depend on these addresses to deliver packets to the correct sub-network.