This document describes the file-sharing protocol for a proposed Common Internet File System (CIFS). CIFS is intended to provide an open cross-platform mechanism for client systems to request file services from server systems over a network. It is based on the standard Server Message Block (SMB) protocol widely in use by personal computers and workstations running a wide variety of operating systems. An earlier version of this protocol was documented as part of the X/OPEN (now Open Group) CAE series of standards [7]; this document updates the specification to include the latest shipping versions, and is published to allow the creation of implementations that interoperate with those implementations.
The scope of this specification is limited to describing requests and responses for file services. Separate specifications exist for clients requesting services other than file services, e.g., print services.
Use of the Internet and the World Wide Web has been characterized by read-only access. Existing protocols such as FTP are good solutions for one-way file transfer. However, new read/write interfaces will become increasingly necessary as the Internet becomes more interactive and collaborative. Adopting a common file-sharing protocol having modern semantics, such as shared files, byte-range locking, coherent caching, change notification, replicated storage, etc., would provide important benefits to the Internet community.
The protocol supports the following features:
The protocol supports the usual set of file operations: open, close, read, write, and seek.
The protocol supports file and record locking, as well as unlocked access to files. Applications that lock files cannot be improperly interfered with by applications that do not; once a file or record is locked, non-locking applications are denied access to the file.
The protocol supports caching, read-ahead, and write-behind, even for unlocked files, as long as they are safe. All these optimizations are safe as long as only one client is accessing a file; read-caching and read-ahead are safe with many clients accessing a file as long as all are just reading. If many clients are writing a file simultaneously, then none are safe, and all file operations have to go to the server. The protocol notifies all clients accessing a file of changes in the number and access mode of clients accessing the file, so that they can use the most optimized safe access method.
Applications can register with a server to be notified if and when file or directory contents are modified. For example, they can use this to know when a display needs to be refreshed, without having to constantly poll the server.
This protocol has several different versions and sub-versions; a particular version is referred to as a dialect. When two machines first come into network contact, they negotiate the dialect to be used. Different dialects can include both new messages as well as changes to the fields and semantics of existing messages in other dialects.
In addition to many built-in file attributes, such as creation and modification times, non-file system attributes can be added by applications, such as the author's name, content description, etc.
The protocol supports file system subtrees, which appear to clients to be a single volume and server, but which actually span multiple volumes and servers. The files and directories of such a subtree can be physically moved to different servers, and their names do not have to change, isolating clients from changes in the server configuration. These subtrees can also be transparently replicated for load sharing and fault tolerance. When a client requests a file, the protocol uses referrals to transparently direct a client to the server that stores it.
The protocol allows clients to resolve server names using any name resolution mechanism. In particular, it allows using the Domain Name System (DNS), permitting access to the file systems of other organizations over the Internet, or hierarchical organization of servers' names within an organization. Earlier versions of the protocol only supported a flat server name space.
The protocol supports the batching of multiple requests into a single message, in order to minimize round trip latencies, even when a later request depends on the results of an earlier one.