We present a new file system that combines name-based and content-based access to files at the same time. Our design allows both methods to be used at any time, thus preserving the benefits of both. Users can create their own name spaces based on queries, on explicit path names, or on any combination interleaved arbitrarily. All regular file operations -- such as adding, deleting, or moving files -- are supported in the same way, and in addition, query consistency is maintained and adapted to what the user is manually doing. One can add, remove, or move results of queries, and in general handle them as if they were regular files. This creates interesting new consistency problems, for which we suggest and implement solutions. Remote le systems or remote query systems (e.g., web search) can be integrated by users into their own coherent name spaces in a clean way. We believe that our design can serve as the basis for the future information-rich file systems, allowing users better handle on their information.

Software development in the future will conducted by "virtual enterprises," consisting of loosely-coupled, widely distributed, autonomous developmentteams.

This paper describes a virtual file system that allows data to be shared among computational grid users distributed across multiple administrative domains. The virtual file system employs software proxies to broker transactions between standard Network File System (NFS) clients and servers, these proxies are dynamically configured and controlled by grid middleware. This technique enables data sharing at the granularity of files, providing a basis for grid-based coordination. The solution works with unmodified applications (even commercial ones) running on standard operating systems and hardware. Therefore, in addition to sharing, the virtual file system can leverage complementary coordination capabilities from legacy solutions based on NFS. Experimental results show that the wide-area performance of the current implementation of the virtual file system depends on application I/O requirements: it is within 1 of native local-area NFS performance for a typical compute-intensive PUNCH application (SimpleScalar), and 5.5 times worse than the local-area performance for an I/O-intensive application (Andrew).