MMMMiiiiccccrrrroooossssoooofffftttt NNNNeeeettttwwwwoooorrrrkkkkssss////OOOOppppeeeennnnNNNNEEEETTTT
FFFFIIIILLLLEEEE SSSSHHHHAAAARRRRIIIINNNNGGGG PPPPRRRROOOOTTTTOOOOCCCCOOOOLLLL
IIIINNNNTTTTEEEELLLL PPPPaaaarrrrtttt NNNNuuuummmmbbbbeeeerrrr 111133338888444444446666
DDDDooooccccuuuummmmeeeennnntttt VVVVeeeerrrrssssiiiioooonnnn 2222....0000
NNNNoooovvvveeeemmmmbbbbeeeerrrr 7777,,,, 1111999988888888
Microsoft Corporation
Intel Corporation
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 2 - November 7, 1988
_1. _I_n_t_r_o_d_u_c_t_i_o_n
This document describes the MSNET/PCNET file sharing proto-
col. Systems can use these protocols to obtain or provide
remote file services in a network environment. These proto-
cols are designed to allow systems to transparently access
files which reside on remote systems. Items which are
mapped into the file space (such as UNIX style "device spe-
cial files") are also transparently shared by these proto-
cols.
When two machines first come into network contact they may
negotiate the use of a higher level "Extension Protocol".
For example, two MS-DOS machines would agree to use the MS-
DOS-specific protocol extensions. These extensions can
include both new messages as well as changes to the fields
and semantics of existing messages. The "Core/Extension
Protocol" definition allows a system to communicate at a
strong, functional level with other "core" machines, and to
communicate in full transparent detail to its "brother" sys-
tems. The ability to negotiate the protocol used across a
given connection is also used, in those cases where multiple
versions of a protocol exist, to ensure that only compatible
versions of the protocol are used.
This document assumes the existence of, but does not
describe, a lower level set of protocols that provide for
virtual circuits and transport between clients and servers.
Further, it does not discuss the mechanism used to "iden-
tify" and "locate" a correspondent in order to establish
said virtual circuit. The details of virtual circuit sup-
port for MS-DOS are described in the document "Transport
Layer Interface".
_2. _M_e_s_s_a_g_e _F_o_r_m_a_t
Every message has a common format. The following C-language
style definition shows that format.
BYTE smb_idf[4]; /* contains 0xFF, 'SMB' */
BYTE smb_com; /* command code */
BYTE smb_rcls; /* error code class */
BYTE smb_reh; /* reserved (contains AH if DOS INT-24 ERR) */
WORD smb_err; /* error code */
BYTE smb_reb; /* reserved */
WORD smb_res[7]; /* reserved */
WORD smb_tid; /* tree id # */
WORD smb_pid; /* caller's process id # */
WORD smb_uid; /* user id # */
WORD smb_mid; /* mutiplex id # */
BYTE smb_wct; /* count of parameter words */
WORD smb_vwv[]; /* variable # words of params */
WORD smb_bcc; /* # bytes of data following */
BYTE smb_data[]; /* data bytes */
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 3 - November 7, 1988
A BYTE is an octet.
A WORD is two bytes.
The bytes within a word are ordered such that the low byte precedes the high byte.
smb_com:command code.
smb_rcls:error class (see below).
smb_ret:error returned (see below).
smb_tid:Used by the server to identify a sub-tree. (see
below)
smb_pid:caller's process id. Generated by the consumer to
uniquely identify a process within the consumers sys-
tem.
smb_mid:this field is reserved for multiplexing multiple
messages on a single Virtual Circuit (VC). A response
message will always contain the same value as the
corresponding request message. This initial version of
the core protocol will not support multiplexing within
a VC. Only one request at a time may be outstanding on
any VC.
_3. _A_r_c_h_i_t_e_c_t_u_r_a_l _M_o_d_e_l
The Network File Access system described in this document
deals with two types of systems on the network -- consumers
and servers. A consumer is a system that requests network
file services and a server is a system that delivers network
file services. Consumers and servers are logical systems; a
consumer and server may coexist in a single physical system.
Consumers are responsible for directing their requests to
the appropriate server. The network addressing mechanism or
naming convention through which the server is identified is
outside the scope of this document.
Each server makes available to the network a self-contained
file structure. There are no storage or service dependen-
cies on any other servers. A file must be entirely con-
tained by a single server.
The core file sharing protocol requires server authentica-
tion of users before file accesses are allowed. Each server
processor authenticates its own users. A user must "login"
to each server that it wishes to access.
This authentication model assumes that the LAN connects
autonomous systems that are willing to make some subset of
their local files available to remote users.
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 4 - November 7, 1988
The following environments exist in the core file sharing
protocol environment.
a) Virtual Circuit Environment. This consists of one VC
established between a consumer system and server sys-
tem. Consumers may have only a single request active
on any VC at any time, i.e., a second request cannot be
initiated until the response to the first has been
received. A VC is formed using transport services.
b) Logon Environment. This is represented by a Tree ID
(TID). A TID uniquely identifies a file sharing connec-
tion between a consumer and server. It also identifies
the scope and type of accesses allowed across the con-
nection. With the exception of the Tree Connect and
Negotiate commands, the TID field in a message must
always contain a valid TID. There may be any number of
file sharing connections per VC.
c) Process Environment. This is represented by a process
ID (PID). A PID uniquely identifies a consumer process
within a given VC environment.
d) File Environment. This is represented by a File Handle
(FID). A FID identifies an open file and is unique
within a given VC environment.
When one of these environments is terminated, all environ-
ments contained within it will be terminated. For example,
if a VC is terminated all PIDs, TIDs and FIDs within it will
be invalidated.
_3._1. _P_r_o_c_e_s_s _M_a_n_a_g_e_m_e_n_t
How and when servers create and destroy processes is, of
course, an implementation issue and there is no requirement
that this be tied in any way to the consumer's process
management. However, it is necessary for the server to be
aware of the consumer's process management activities as
files are accessed on behalf of consumer processes. There-
fore the file sharing protocol includes appropriate notifi-
cations.
All messages, except Negotiate, include a process ID (PID)
to indicate which user process initiated a request. Consu-
mers inform servers of the creation of a new process by sim-
ply introducing a new PID into the dialogue. Process des-
truction must be explicitly indicated and the "Process Exit"
command is provided for this purpose. The consumer must send
a Process Exit command whenever a user process is destroyed.
This enables the server to free any resources (e.g., locks)
reserved by that process as well as perform any local pro-
cess management activities that its implementation might
require.
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 5 - November 7, 1988
_4. _F_i_l_e _S_h_a_r_i_n_g _C_o_n_n_e_c_t_i_o_n_s
The networks using this file sharing protocol will contain
not only multi-user systems with user based protection
models, but single-user systems that have no concept of
user-ids or permissions. Once these machines are connected
to the network, however, they are in a multi-user environ-
ment and need a method of access control. First, unpro-
tected machines need to be able to provide some sort of
bona-fides to other net machines which do have permissions,
secondly unprotected machines need to control access to
their files by others.
This protocol defines a mechanism that enables the network
software to provide the protection where it is missing from
the operating system, and supports user based protection
where it is provided by the operating system. The mechanism
also allows machines with no concept of user-id to demon-
strate access authorization to machines which do have a per-
mission mechanism. Finally, the permission protocol is
designed so that it can be omitted if both machines share a
common permission mechanism.
This protocol, called the "tree connection" protocol, does
not specify a user interface. A possible user interface
will be described by way of illustration.
_4._1. _U_n_p_r_o_t_e_c_t_e_d _S_e_r_v_e_r _M_a_c_h_i_n_e_s
The following examples apply to access to serving systems
which do not have a permission mechanism.
a) NET SHARE
By default (on unprotected machines) all network requests
are refused as unauthorized. Should a user wish to allow
access to some or all of his files he offers access to an
arbitrary set of subtrees by specifying each subtree and a
password.
Examples:
NET SHARE \dir1 "bonzo"
assign password "bonzo" to all files within directory
"dir1" and its subdirectories.
NET SHARE \ " " RO
NET SHARE \work "flipper" RW
offer read-only access to everything (all files are
within the root directory or its subdirectories) Offer
read-write access to all files within the \work
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 6 - November 7, 1988
directory and its subdirectories.
b) NET USE
Other users can gain access to one or more offered subtrees
via the NET USE command. Once the NET USE command is issued
the user can access the files freely without further special
requirements.
Examples:
1. NET USE \\machine-name\dir1 "bonzo"
now any pathname starting with \\machine-name\dir1 is
valid.
2. NET USE \\machine-name\
3. NET USE \\machine-name\work "flipper"
Now any read request to any file on that machine is
valid. Read-write requests only succeed to files whose
pathnames start with \\machine-name\work
The requester must remember the machine-name pathname prefix
combination supplied with the NET USE request and associate
it with the index value returned by the server. Subsequent
requests using this index must include only the pathname
relative to the connected subtree as the server treats the
subtree as the root directory.
When the requester has a file access request for the server,
it looks through its list of prefixes for that machine and
selects the most specific (the longest) match. It then
includes the index associated with this prefix in his
request along with the remainder of the pathname.
Note that one always offers a directory and all files under-
neath that directory are then affected. If a particular
file is within the range of multiple offer ranges, connect-
ing to any of the offer ranges gains access to the file with
the permissions specified for the offer named in the NET
USE. The server will not check for nested directories with
more restrictive permissions.
_4._2. _P_r_o_t_e_c_t_e_d _S_e_r_v_e_r _M_a_c_h_i_n_e_s
Servers with user based file protection schemes will inter-
pret the Tree Connect command slightly differently from sys-
tems with file oriented file protection schemes. They
interpret the "name" parameter as a username rather than a
pathname. When this request is received, the username is
validated and a TID representing that authenticated instance
of the user is returned. This TID must be included in all
further requests made on behalf of the user.
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 7 - November 7, 1988
The permission-based system need not execute a NET SHARE
command; instead it sets up name/password (or whatever)
information in its user definition files. The accessing
user would type
NET USE \\machine-name\account-name <password>
and thereby "login" to the serving machine. He need not
specify subtrees and so forth because the account-
name/password pair establishes access permissions to every-
thing on that machine.
This variation of Tree Connect is an aspect of the the
server's file system. Servers with user based protection
schemes will always interpret the name supplied with Tree
Connect as a user name. Users of Tree Connect simply pro-
vide a "name" and its associated "password"; they do not
need to be aware of the server's interpretation of that
name. If the name and password are successfully authenti-
cated the caller receives access to the set of files pro-
tected by the name in the modes allowed by the server (also
determined by the name/password pair).
_4._3. _C_o_n_n_e_c_t_i_o_n _P_r_o_t_o_c_o_l_s
The NET SHARE command generates no network messages. The
server package remembers the pathname prefix and the pass-
word.
The NET USE command generates a message containing the
path/username and the password. The serving machine veri-
fies the combination and returns an error code or an iden-
tifier. The full name (path or user) is included in the
Tree Connect request message and the identifier identifying
the connection is returned in the smb_tid field. The mean-
ing of this identifier (tid) is server specific; the reques-
ter must not associate any specific meaning to it.
The server makes whatever use of the tid field it desires.
Normally it is an index into a server table which allows the
server to optimize its response.
_4._4. _T_r_e_e _C_o_n_n_e_c_t
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 8 - November 7, 1988
8 ________________________________________________________
>From Consumer To Consumer
8 ________________________________________________________
smb_com SMBtcon smb_com SMBtcon
smb_wct 0 smb_wct 2
smb_bcc min=4 smb_vwv[0] max xmit size
smb_buf[] ASCII -- 04 smb_vwv[1] TID
path/username smb_bcc 0
ASCII -- 04
password
ASCII -- 04
dev name
8 ________________________________________________________
7 |7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|
The device name is either <device>: for block device or
LPT1: for a character device.
The path/username must be specified from the network root
(including \\). The TID field in the request message is
ignored by the server. The maximum transmit size field in
the response message indicates the maximum size message that
the server can handle. The consumer should not generate
messages, nor expect to receive responses, larger than this.
This should be constant for a given server.
Tree Connects must be issued for all subtrees accessed, even
if they contain a null password.
Tree Connect may generate the following errors:
Error Class ERRDOS:
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRbadpw
ERRinvnetname
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_4._5. _T_r_e_e _D_i_s_c_o_n_n_e_c_t
8 _______________________________________
>From Consumer To Consumer
8 _______________________________________
smb_com SMBtdis smb_com SMBtdis
smb_wct 0 smb_wct 0
smb_bcc 0 smb_bcc 0
9Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 9 - November 7, 1988
8 _______________________________________
7 |
7 |
7 |
The file sharing connection identified by the TID is logi-
cally disconnected from the server. The TID will be invali-
dated; it will not be recognized if used by the consumer for
subsequent requests.
Tree Disconnect may generate the following errors:
Error Class ERRDOS:
<implementation specific>
Error Class ERRSRV:
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5. _F_i_l_e _S_h_a_r_i_n_g _C_o_m_m_a_n_d_s
The message definitions in this section indicate the command
code and include the balance of the definition commencing at
the field smb_wct. The omitted fields (smb_cls through
smb_mid) are constant in the format and meaning defined in
Section 1.0. When an error is encountered a server may
return only the header portion of the response (i.e.,
smb_wct and smb_bcc both contain zero). The data objects
used by these commands are described in section 6.0.
The use of commands other than those defined in this section
will have undefined results.
_5._1. _O_p_e_n _F_i_l_e
8 __________________________________________________________
>From Consumer To Consumer
8 __________________________________________________________
smb_com SMBopen smb_com SMBopen
smb_wct 2 smb_wct 7
smb_vwv[0] r/w/share smb_vwv[0] file handle
smb_vwv[1] attribute smb_vwv[1] attribute
smb_bcc min = 2 smb_vwv[2] time1 low
smb_buf[] ASCII -- 04 smb_vwv[3] time1 high
file pathname smb_vwv[4] file size low
smb_vwv[5] file size high
smb_vwv[6] access allowed
smb_bcc 0
8 __________________________________________________________
8Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
9
8File Sharing Protocol - 10 - November 7, 1988
999 |99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|
77777777777777777777777777777777777777777799 |99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|
77777777777777777777777777777777777777777799 |99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|
7777777777777777777777777777777777777777This message is sent to obtain a file handle for a data
file. The relevant tree id and any necessary additional
pathname are passed. The handle returned can be used in
subsequent read, write, lock, unlock and close messages.
The file size and last modification time are also returned.
The r/w/share word controls the mode. The file will be
opened only if the requester has the appropriate permis-
sions. The r/w/share word has the following format and
values.
r/w/share format: - - - - - - - - rxxx yyyy
where: r = reserved
9 xxx = 0 --
7 MS-DOS Compatibility mode (exclusive to a VC, but that VC may have multiple
opens). Support of this mode is optional. However, if it is not supported
or is mapped to exclusive open modes, some existing MS-DOS applications may
not work with network files. If reading map to deny write, otherwise map to
deny read/write.
1 -- Deny read/write (exclusive to this open operation).
2 -- Deny write -- other users may access file in READ mode.
3 --
7 Deny read -- other users may access file in WRITE mode. Support of this mode
is optional.
4 -- Deny none -- allow other users to access file in any mode for which they have
permission.
9 yyyy = 0 -- Open file for reading.
1 -- Open file for writing.
2 -- Open file for reading and writing.
9 rxxx yyyy = 11111111 (hex FF)
7 FCB open: This type of open will cause an MS-DOS compatibility mode open with
the read/write modes set to the maximum permissible, i.e., if the requester
can have read and write access on the file, it will be opened in read/write
mode.
The response message indicates the access permissions actu-
ally allowed in the "access allowed" field. This field may
have the following values:
0 = read-only
1 = write-only
2 = read/write
File Sharing Notes:
1. File Handles (FIDs) are contained within the Virtual
Circuit (VC) environment. A PID may reference any FID
established by itself or any other PID within its VC.
The actual accesses allowed through the FID will depend
on the open and deny modes specified when the file was
opened (see below).
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 11 - November 7, 1988
2. The MS-DOS compatibility mode of file open provides
exclusion at the VC level. A file open in compatibil-
ity mode may be opened (also in compatibility mode) any
number of times for any combination of reading and
writing (subject to the user's permissions) by any PID
within the owning VC. If the first VC has the file
open for writing, then the file may not be opened in
any way by any PID within another VC. If the first VC
has the file open only for reading, then other VCs may
open the file, in compatibility mode, for reading.
Once multiple VCs have the file open for reading, no VC
is permitted to open the file for writing. No VC or
PID may open the file in any mode other than compati-
bility mode.
3. The other file exclusion modes (Deny read/write, Deny
write, Deny read, Deny none) provide exclusion at the
file level. A file opened in any "Deny" mode may be
opened again only for the accesses allowed by the Deny
mode (subject to the user's permissions). This is true
regardless of the identity of the second opener -- a
PID within another VC, a PID within the same VC, or the
PID that already has the file open. For example, if a
file is open in "Deny write" mode a second open may
only obtain read permission to the file.
4. Although FIDs are available to all PIDs on a VC, PIDs
other than the owner may not have the full access
rights specified in the open mode by the FID's creator.
If the open creating the FID specified a deny mode,
then any PID using the FID, other than the creating
PID, will have only those access rights determined by
"anding" the open mode rights and the deny mode rights,
i.e., the deny mode is checked on all file accesses.
For example, if a file is opened for Read/Write in Deny
write mode, then other VC PIDs may only read from the
FID and cannot write; if a file is opened for Read in
Deny read mode, then the other VC PIDs can neither read
nor write the FID.
If a file cannot be opened for any reason, including a con-
flict of share modes, a reply message indicating the cause
of the failure will be returned.
Open may generate the following errors:
Error Class ERRDOS:
ERRbadfile
ERRnofids
ERRnoaccess
ERRshare
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 12 - November 7, 1988
Error Class ERRSRV:
ERRerror
ERRaccess
ERRinvnid
ERRinvdevice
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._2. _C_r_e_a_t_e _F_i_l_e
8 _______________________________________________________
>From Consumer To Consumer
8 _______________________________________________________
smb_com SMBcreate smb_com SMBcreate
smb_wct 3 smb_wct 1
smb_vwv[0] attribute smb_vwv[0] file handle
smb_vwv[1] time low smb_bcc 0
smb_vwv[2] time high
smb_bcc min = 2
smb_buf[] ASCII -- 04
file pathname
8 _______________________________________________________
7 |7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
This message is sent to create a new data file or truncate
an existing data file to length zero, and open the file.
The handle returned can be used in subsequent read, write,
lock, unlock and close messages.
Unprotected servers will require requesters to have create
permission for the subtree containing the file in order to
create a new file, or write permission for the subtree in
order to truncate an existing one. The newly created file
will be opened in compatibility mode with the access mode
determined by the containing subtree permissions.
Protected servers will require requesters to have write per-
mission on the file's parent directory in order to create a
new file, or write permission on the file itself in order to
truncate it. The access permissions granted on a created
file will be read/write permission for the creator. Access
permissions for truncated files are not modified. The newly
created or truncated file is opened in
read/write/compatibility mode.
Support of the create time supplied in the request is
optional.
Create may generate the following errors:
9Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 13 - November 7, 1988
Error Class ERRDOS:
ERRbadpath
ERRnofids
ERRnoaccess
ERRbadaccess
Error Class ERRSRV:
ERRerror
ERRaccess
ERRinvnid
ERRinvdevice
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._3. _C_l_o_s_e _F_i_l_e
8 _______________________________________________
>From Consumer To Consumer
8 _______________________________________________
smb_com SMBclose smb_com SMBclose
smb_wct 3 smb_wct 0
smb_vwv[0] file handle smb_bcc 0
smb_vwv[1] time low
smb_vwv[2] time high
smb_bcc 0
8 _______________________________________________
7 |7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|
The close message is sent to invalidate a file handle for
the requesting process. All locks held by the requesting
process on the file will be "unlocked". The requesting pro-
cess can no longer use the file handle for further file
access requests. The new modification time may be passed to
the server. Server support of the modification time is
optional; it may be ignored.
Close will cause all the file's buffers to be flushed to
disk.
Close may generate the following errors:
Error Class ERRDOS:
ERRbadfid
ERRnoaccess
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 14 - November 7, 1988
Error Class ERRSRV:
ERRerror
ERRinvdevice
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._4. _F_l_u_s_h _F_i_l_e
8 _______________________________________________
>From Consumer To Consumer
8 _______________________________________________
smb_com SMBflush smb_com SMBflush
smb_wct 1 smb_wct 0
smb_vwv[0] file handle smb_bcc 0
smb_bcc 0
8 _______________________________________________
7 |7|7|7|7|7|
|7|7|7|7|7|
|7|7|7|7|7|
The flush message is sent to ensure all data and allocation
information for the corresponding file has been written to
non-volatile storage. When the file handle has a value -1
(hex FFFF) the server will perform a flush for all file han-
dles associated with the consumer's process. The response
is not sent until the writes are complete.
Note that this protocol does not require that only the
specific file's data be written (flushed). It specifies
that "at least" the file's data be written.
Flush may generate the following errors:
Error Class ERRDOS:
ERRbadfid
ERRnoaccess
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvdevice
ERRinvnid
<implementation specific>
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 15 - November 7, 1988
Error Class ERRHRD:
<implementation specific>
_5._5. _R_e_a_d
8_________________________________________________________________
>From Consumer To Consumer
8_________________________________________________________________
smb_com SMBread smb_com SMBread
smb_wct 5 smb_wct 5
smb_vwv[0] file handle smb_vwv[0] count
smb_vwv[1] count of bytes smb_vwv[1-4] reserved (MBZ)
smb_vwv[2] offset low smb_bcc length of data + 3
smb_vwv[3] offset high smb_buf[] Data Block -- 01
smb_vwv[4] count left length of data
smb_bcc 0 data
8_________________________________________________________________
7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
The read message is sent to read bytes of a data file. The
count of bytes field is used to specify the requested number
of bytes. The offset field specifies the offset in the file
of the first byte to be read. The count left field is
advisory. If the value is not zero, then it is taken as an
estimate of the total number of bytes that will be read --
including those read by this request. This additional
information may be used by the server to optimize buffer
allocation or read-ahead.
The count field in the response message indicates the number
of bytes actually being returned. The count returned may be
less than the count requested only if a read specifies bytes
beyond the current file size. In this case only the bytes
that exist are returned. A read completely beyond the end
of file will result in a response of length zero. This is
the only circumstance when a zero length response is gen-
erated. A count returned which is less than the count
requested is the end of file indicator.
If a Read requests more data than can be placed in a message
of the max-xmit-size for the TID specified, the server will
abort the virtual circuit to the consumer.
Read may generate the following errors:
Error Class ERRDOS:
ERRnoaccess
ERRbadfid
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 16 - November 7, 1988
Error Class ERRSRV:
ERRerror
ERRinvdevice
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._6. _W_r_i_t_e
8 _________________________________________________________
>From Consumer To Consumer
8 _________________________________________________________
smb_com SMBwrite smb_com SMBwrite
smb_wct 5 smb_wct 1
smb_vwv[0] file handle smb_vwv[0] count
smb_vwv[1] count of bytes smb_bcc 0
smb_vwv[2] offset low
smb_vwv[3] offset high
smb_vwv[4] count left
smb_bcc length of data + 3
smb_buf[] Data Block -- 01
length of data
data
8 _________________________________________________________
7 |7|7|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|7|7|
The write message is sent to write bytes into a data file.
The count of bytes field specifies the number of bytes to be
written. The offset field specifies the offset in the file
of the first byte to be written. The count left field is
advisory. If the value is not zero, then it is taken as an
estimate of the number of bytes that will be written --
including those written by this request. This additional
information may be used by the server to optimize buffer
allocation.
The count field in the response message indicates the actual
number of bytes written, and for successful writes will
always equal the count in the request message. If the
number of bytes written differs from the number requested
and no error is indicated, then the server has no disk space
available with which to satisfy the complete write.
When a write specifies a byte range beyond the current end
of file, the file will be extended. Any bytes between the
previous end of file and the requested offset will be set to
zero (ASCII nul).
When a write specifies a length of zero, the file will be
9Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 17 - November 7, 1988
truncated to the length specified by the offset.
If a Write sends a message of length greater than the max-
xmit-size for the TID specified, the server will abort the
virtual circuit to the consumer.
Write may generate the following errors:
Error Class ERRDOS:
ERRnoaccess
ERRbadfid
Error Class ERRSRV:
ERRerror
ERRinvdevice
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._7. _S_e_e_k
8 _____________________________________________________
>From Consumer To Consumer
8 _____________________________________________________
smb_com SMBlseek smb_com SMBlseek
smb_wct 4 smb_wct 2
smb_vwv[0] file handle smb_vwv[0] offset-low
smb_vwv[1] mode smb_vwv[1] offset-high
smb_vwv[2] offset-low smb_bcc 0
smb_vwv[2] offset-high
smb_bcc min = 0
8 _____________________________________________________
7 |7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|
The seek message is sent to set the current file pointer for
the requesting process. The starting point of the seek is
set by the "mode" field in the request. This may have the
following values:
0 = seek from start of file
1 = seek from current file pointer
2 = seek from end of file
The response returns the new file pointer expressed as the
offset from the start of the file, and may be beyond the
current end of file. An attempt to seek to before the start
of file set the file pointer to start of file.
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 18 - November 7, 1988
Note: the "current file pointer" at the start of this com-
mand reflects the offset plus data length specified in the
previous read, write or seek request, and the pointer set by
this command will be replaced by the offset specified in the
next read, write or seek command.
Seek may generate the following errors:
Error Class ERRDOS:
ERRnoaccess
Errbadfid
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._8. _C_r_e_a_t_e _D_i_r_e_c_t_o_r_y
8 _______________________________________________
>From Consumer To Consumer
8 _______________________________________________
smb_com SMBmkdir smb_com SMBmkdir
smb_wct 0 smb_wct 0
smb_bcc min = 2 smb_bcc 0
smb_buf[] ASCII -- 04
dir pathname
8 _______________________________________________
7 |7|7|7|7|7|7|
|7|7|7|7|7|7|
|7|7|7|7|7|7|
The create directory message is sent to create a new direc-
tory. The appropriate TID and additional pathname are
passed. The directory must not exist for it to be created.
Unprotected servers will require requesters to have create
permission for the subtree containing the directory in order
to create a new directory. The creator's access rights to
the new directory will be determined by the containing sub-
tree permissions.
Protected servers will require requesters to have write per-
mission on the new directory's parent directory. The access
permissions granted on a created directory will be
read/write permission for the creator.
Create Directory may generate the following errors:
9Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 19 - November 7, 1988
Error Class ERRDOS:
ERRbadpath
ERRnoaccess
Error Class ERRSRV:
ERRerror
ERRaccess
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._9. _D_e_l_e_t_e _D_i_r_e_c_t_o_r_y
8 _______________________________________________
>From Consumer To Consumer
8 _______________________________________________
smb_com SMBrmdir smb_com SMBrmdir
smb_wct 0 smb_wct 0
smb_bcc min = 2 smb_bcc 0
smb_buf[] ASCII -- 04
dir pathname
8 _______________________________________________
7 |7|7|7|7|7|7|
|7|7|7|7|7|7|
|7|7|7|7|7|7|
The delete directory message is sent to delete an empty
directory. The appropriate TID and additional pathname are
passed. The directory must be empty for it to be deleted.
Unprotected servers will require the requester to have write
permission to the subtree containing the directory to be
deleted.
Protected servers will require the requester to have write
permission to the target directory's parent directory.
The effect of a delete will be, to some extent, dependent on
the nature of the server. Normally only the referenced
directory name is deleted, the directory contents are only
deleted when all the directory's names have been deleted.
In some cases a delete will cause immediate destruction of
the directory contents.
Delete Directory may generate the following errors:
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 20 - November 7, 1988
Error Class ERRDOS:
ERRbadpath
ERRnoaccess
ERRremcd
Error Class ERRSRV:
ERRerror
ERRaccess
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._1_0. _D_e_l_e_t_e _F_i_l_e
8 __________________________________________________
>From Consumer To Consumer
8 __________________________________________________
smb_com SMBunlink smb_com SMBunlink
smb_wct 1 smb_wct 0
smb_vwv[0] attribute smb_bcc 0
smb_bcc min = 2
smb_buf[] ASCII -- 04
file pathname
8 __________________________________________________
7 |7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|
The delete file message is sent to delete a data file. The
appropriate TID and additional pathname are passed. A file
must exist for it to be deleted. Read only files may not be
deleted, the read-only attribute must be reset prior to file
deletion.
Multiple files may be deleted in response to a single
request as Delete File supports "wild cards" in the file
name (last component of the pathname). "?" is the wild card
for single characters, "*" or "null" will match any number
of filename characters within a single part of the filename
component. The filename is divided into two parts -- an
eight character name and a three character extension. The
name and extension are divided by a ".".
If a filename part commences with one or more "?"s then
exactly that number of characters will be matched by the
wildcards, e.g., "??x" will equal "abx" but not "abcx" or
"ax". When a filename part has trailing "?"s then it will
match the specified number of characters or less, e.g.,
"x??" will match "xab", "xa" and "x", but not "xabc". If
9Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 21 - November 7, 1988
only "?"s are present in the filename part, then it is han-
dled as for trailing "?"s
"*" or "null" match entire pathname parts, thus "*.abc" or
".abc" will match any file with an extension of "abc".
"*.*", "*" or "null" will match all files in a directory.
The attribute field indicates the attributes that the target
file(s) must have. If the attribute is zero then only nor-
mal files are deleted. If the system file or hidden attri-
butes are specified then the delete is inclusive -- both the
specified type(s) of files and normal files are deleted.
Unprotected servers will require the requester to have write
permission to the subtree containing the file to be deleted.
Protected servers will require the requester to have write
permission to the target file's parent directory.
The effect of a delete will be, to some extent, dependent on
the nature of the server. Normally only the referenced file
name is deleted, the file contents are only deleted when all
the file's names have been deleted and all file handles
associated with it have been destroyed (closed).
In some cases (notably MS-DOS) a delete will cause immediate
destruction of the file contents and invalidation of all
fids associated with the file.
Delete File may generate the following errors:
Error Class ERRDOS:
ERRbadfile
ERRnoaccess
Error Class ERRSRV:
ERRerror
ERRaccess
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 22 - November 7, 1988
_5._1_1. _R_e_n_a_m_e _F_i_l_e
8 ___________________________________________________
>From Consumer To Consumer
8 ___________________________________________________
smb_com SMBmv smb_com SMBmv
smb_wct 1 smb_wct 0
smb_vwv[0] attribute smb_bcc 0
smb_bcc min = 4
smb_buf[] ASCII -- 04
old file pathname
ASCII -- 04
new file pathname
8 ___________________________________________________
7 |7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
The rename file message is sent to change the name of a
file. The first file pathname must exist and the second
must not. Both pathnames must be relative to the tid speci-
fied in the request. Open files may be renamed.
Multiple files may be renamed in response to a single
request as Rename File supports "wild cards" in the file
name (last component of the pathname). The wild card match-
ing algorithm is described in the "Delete File" description.
The attribute field indicates the attributes that the target
file(s) must have. If the attribute is zero then only nor-
mal files are renamed. If the system file or hidden attri-
butes are specified then the rename is inclusive -- both the
specified type(s) of files and normal files are renamed.
Unprotected servers require the requester to have both read
and create permissions to the referenced subtree.
Protected servers require the requester to have write per-
mission to the parent directories of both the source and
destination files.
Rename is guaranteed to succeed if only the last component
of the file pathnames differs. Other rename requests may
succeed depending on the server implementation used.
Rename may generate the following errors:
Error Class ERRDOS:
ERRbadfile
ERRnoaccess
ERRdiffdevice
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 23 - November 7, 1988
Error Class ERRSRV:
ERRerror
ERRaccess
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._1_2. _G_e_t _F_i_l_e _A_t_t_r_i_b_u_t_e_s
8___________________________________________________________
>From Consumer To Consumer
8___________________________________________________________
smb_com SMBgetatr smb_com SMBgetatr
smb_wct 0 smb_wct 10
smb_bcc min = 2 smb_vwv[0] attribute
smb_buf[] ASCII -- 04 smb_vwv[1] time1 low
file pathname smb_vwv[2] time1 high
smb_vwv[3] file size low
smb_vwv[4] file size high
smb_vwv[5-9] reserved (MBZ)
smb_bcc 0
8___________________________________________________________
7|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|
The get file attributes message is sent to obtain informa-
tion about a file. The attribute, time1, and file size
fields must contain valid values for data files. The attri-
bute and time1 fields must contain valid values for direc-
tories.
Get File Attributes may generate the following errors:
Error Class ERRDOS:
ERRbadfile
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 24 - November 7, 1988
_5._1_3. _S_e_t _F_i_l_e _A_t_t_r_i_b_u_t_e_s
8 _____________________________________________________
>From Consumer To Consumer
8 _____________________________________________________
smb_com SMBsetatr smb_com SMBsetatr
smb_wct 8 smb_wct 0
smb_vwv[0] attribute smb_bcc 0
smb_vwv[1] time1 low
smb_vwv[2] time1 high
smb_vwv[3-7] reserved (MBZ)
smb_bcc min = 2
smb_buf[] ASCII -- 04
file pathname
smb_nul[] ASCII -- 04
null string
8 _____________________________________________________
7 |7|7|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|7|7|
The set file attributes message is sent to change the infor-
mation about a file. Support of all parameters is optional.
A server which does not implement one of the parameters will
ignore that field. If the time1 field contains zero then the
file's time is not changed.
Unprotected servers require the requester to have write per-
mission to the subtree containing the referenced file.
Protected servers will allow the owner of the file to use
this command. Other legitimate users will be server depen-
dent.
Set File Attributes may generate the following errors:
Error Class ERRDOS:
ERRbadfunc
ERRbadpath
ERRnoaccess
Error Class ERRSRV:
ERRerror
ERRinvnid
ERRaccess
<implementation specific>
Error Class ERRHRD:
<implementation specific>
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 25 - November 7, 1988
_5._1_4. _L_o_c_k _R_e_c_o_r_d
8 ______________________________________________
>From Consumer To Consumer
8 ______________________________________________
smb_com SMBlock smb_com SMBlock
smb_wct 5 smb_wct 0
smb_vwv[0] file handle smb_bcc 0
smb_vwv[1] count low
smb_vwv[2] count high
smb_vwv[3] offset low
smb_vwv[4] offset high
smb_bcc 0
8 ______________________________________________
7 |7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
The lock record message is sent to lock the given byte
range. More than one non-overlapping byte range may be
locked in a given file. Locks are coercive in nature. They
prevent attempts to lock, read or write the locked portion
of the file. Overlapping locks are not allowed. File
addresses beyond the current end of file may be locked.
Such locks will not cause allocation of file space.
Locks may only be unlocked by the process (pid) that per-
formed the lock. The ability to perform locks is not tied
to any file access permission.
Lock may generate the following errors:
Error Class ERRDOS:
ERRbadfid
ERRlock
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvdevice
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._1_5. _U_n_l_o_c_k _R_e_c_o_r_d
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 26 - November 7, 1988
8 ________________________________________________
>From Consumer To Consumer
8 ________________________________________________
smb_com SMBunlock smb_com SMBunlock
smb_wct 5 smb_wct 0
smb_vwv[0] file handle smb_bcc 0
smb_vwv[1] count low
smb_vwv[2] count high
smb_vwv[3] offset low
smb_vwv[4] offset high
smb_bcc 0
8 ________________________________________________
7 |7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
The unlock record message is sent to unlock the given byte
range. The byte range must be identical to that specified
in a prior successful lock request, and the unlock requester
(pid) must be the same as the lock holder. If an unlock
references an address range that is not locked it is treated
as a no-op -- no action is taken and no error is generated.
Unlock may generate the following errors:
Error Class ERRDOS:
ERRbadfid
ERRlock
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvdevice
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._1_6. _C_r_e_a_t_e _T_e_m_p_o_r_a_r_y _F_i_l_e
8__________________________________________________________________
>From Consumer To Consumer
8__________________________________________________________________
smb_com SMBctemp smb_com SMBctemp
smb_wct 3 smb_wct 1
smb_vwv[0] attribute smb_vwv[0] file handle
smb_vwv[1] time low smb.bcc min = 2
smb_vwv[2] time high smb_buf[] ASCII -- 04
smb_bcc min = 2 new file pathname
smb_buf[] ASCII -- 04
directory pathname
8__________________________________________________________________
8Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
9
8File Sharing Protocol - 27 - November 7, 1988
9
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
7777777777777777777777777777777777777777777799 |99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|
7777777777777777777777777777777777777777777799 |99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|99|
777777777777777777777777777777777777777777The server creates a data file in the directory specified in
the request message and assigns a unique name to it. The
file's name is returned to the requester. The file is
opened in compatibility mode with read/write access for the
requester.
Unprotected servers will require requesters to have create
permission for the subtree containing the file. The newly
created file will be opened in compatibility mode with the
access mode determined by the containing subtree permis-
sions.
Protected servers will require requesters to have write per-
mission on the file's parent directory. The access permis-
sions granted on a created file will be read/write permis-
sion for the creator. The newly created or truncated file
is opened in read/write/compatibility mode.
Support of the create time supplied in the request is
optional.
Create Temporary File may generate the following errors.
Error Class ERRDOS:
ERRbadpath
ERRnofids
ERRnoaccess
Error Class ERRSRV:
ERRerror
ERRaccess
ERRinvnid
ERRinvdevice
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._1_7. _P_r_o_c_e_s_s _E_x_i_t
8 _______________________________________
>From Consumer To Consumer
8 _______________________________________
smb_com SMBexit smb_com SMBexit
smb_wct 0 smb_wct 0
smb_bcc 0 smb_bcc 0
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 28 - November 7, 1988
8 _______________________________________
7 |
7 |
7 |
This command informs the server that a consumer process has
terminated. The server will close all files opened by the
named process. This will automatically release all locks
the process holds. Note that there is not a start process
message, process-ids are assigned by the consumer.
Process Exit may generate the following errors:
Error Class ERRDOS:
none
Error Class ERRSRV:
ERRerror
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._1_8. _M_a_k_e _N_e_w _F_i_l_e
8 _______________________________________________________
>From Consumer To Consumer
8 _______________________________________________________
smb_com SMBmknew smb_com SMBmknew
smb_wct 3 smb_wct 1
smb_vwv[0] attribute smb_vwv[0] file handle
smb_vwv[1] time low smb_bcc 0
smb_vwv[2] time high
smb_bcc min = 2
smb_buf[] ASCII -- 04
file pathname
8 _______________________________________________________
7 |7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
The make new file message is sent to create a new data file.
It is functionally equivalent to the create message, except
it will always fail if the file already exists.
Make New File may generate the following errors:
Error Class ERRDOS:
ERRbadpath
ERRnofids
ERRnoaccess
<implementation specific>
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 29 - November 7, 1988
Error Class ERRSRV:
ERRerror
ERRaccess
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._1_9. _C_h_e_c_k _P_a_t_h
8 ___________________________________________________
>From Consumer To Consumer
8 ___________________________________________________
smb_com SMBchkpath smb_com SMBchkpath
smb_wct 0 smb_wct 0
smb_bcc min = 2 smb_bcc 0
smb_buf[] ASCII -- 04
directory path
8 ___________________________________________________
7 |7|7|7|7|7|7|
|7|7|7|7|7|7|
|7|7|7|7|7|7|
The check path message is used to verify that a path exists
and is a directory. No error is returned if the given path
exists and the requester has read access to it. Consumer
machines which maintain a concept of a "working directory"
will find this useful to verify the validity of a "change
working directory" command. Note that the servers do NOT
have a concept of working directory. The consumer must
always supply full pathnames (relative to the tid).
Check Path may generate the following errors:
Error Class ERRDOS:
ERRbadpath
ERRnoaccess
Error Class ERRSRV:
ERRerror
ERRaccess
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 30 - November 7, 1988
_5._2_0. _G_e_t _S_e_r_v_e_r _A_t_t_r_i_b_u_t_e_s
8______________________________________________________________________
>From Consumer To Consumer
8______________________________________________________________________
smb_com SMBdskattr smb_com SMBdskattr
smb_wct 0 smb_wct 5
smb_bcc 0 smb_vwv[0] # allocation units/server
smb_vwv[1] # blocks/allocation unit
smb_vwv[2] # block size (in bytes)
smb_vwv[3] # free allocation units
smb_vwv[4] reserved (media identifier code)
smb_bcc 0
8______________________________________________________________________
7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
This command is used to determine the total server capacity
and remaining free space. The distinction between alloca-
tion units and disk blocks allows the use of the protocol
with operating systems which allocate disk space in units
larger than the physical disk block.
The blocking/allocation units used in this response may be
independent of the actual physical or logical
blocking/allocation algorithm(s) used internally by the
server. However, they must accurately reflect the amount of
space on the server.
The default value for smb_vwv[4] is zero.
Get Server Attributes may generate the following errors:
Error Class ERRDOS:
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 31 - November 7, 1988
_5._2_1. _N_e_g_o_t_i_a_t_e _P_r_o_t_o_c_o_l
8 _____________________________________________________
>From Consumer To Consumer
8 _____________________________________________________
smb_com SMBnegprot smb_com SMBnegprot
smb_wct 0 smb_wct 1
smb_bcc min = 2 smb_vwv[0] index
smb_buf[] Dialect -- 02 smb_bcc 0
dialect0
.
.
Dialect -- 02
dialectn
8 _____________________________________________________
7 |7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|
The consumer sends a list of dialects that he can communi-
cate with. The response is a selection of one of those
dialects (numbered 0 through n) or -1 (hex FFFF) indicating
that none of the dialects were acceptable. The negotiate
message is binding on the virtual circuit and must be sent.
One and only one negotiate message may be sent, subsequent
negotiate requests will be rejected with an error response
and no action will be taken.
The protocol does not impose any particular structure to the
dialect strings. Implementors of particular protocols may
choose to include, for example, version numbers in the
string.
The dialect string for the protocol specified in this docu-
ment is:
PC NETWORK PROGRAM 1.0
Negotiate may generate the following errors:
Error Class ERRDOS:
<implementation specific>
Error Class ERRSRV:
ERRerror
<implementation specific>
Error Class ERRHRD:
<implementation specific>
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 32 - November 7, 1988
_5._2_2. _F_i_l_e _S_e_a_r_c_h
8_______________________________________________________________________
>From Consumer To Consumer
8_______________________________________________________________________
smb_com SMBsearch smb_com SMBsearch
smb_wct 2 smb_wct 1
smb_vwv[0] max-count smb_vwv[0] count-returned
smb_vwv[1] attribute smb_bcc min = 3
smb_bcc min = 5 smb_buf[] Variable block -- 05
smb_buf[] ASCII -- 04 length of data
file pathname directory entries
Variable block -- 05
length of data
search status
8_______________________________________________________________________
7|7|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|7|
This command is used to search directories. The file path
name in the request specifies the file to be sought. The
attribute field indicates the attributes that the file must
have. If the attribute is zero then only normal files are
returned. If the system file, hidden or directory attri-
butes are specified then the search is inclusive -- both the
specified type(s) of files and normal files are returned.
If the volume label attribute is specified then the search
is exclusive, and only the volume label entry is returned
The max-count field specifies the number of directory
entries to be returned. The response will contain one or
more directory entries as determined by the count-returned
field. No more than max-count entries will be returned.
Only entries that match the sought filename/attribute will
be returned.
The search-status field must be null (length = 0) on the
initial search request. Subsequent search requests intended
to continue a search must contain the search-status field
extracted from the last directory entry of the previous
response. The search-status field is self-contained, for on
calls containing a search-status neither the attribute or
pathname fields will be valid in the request. Search-status
has the following format:
BYTE sr_res; /* reserved:
bit 7 - reserved for consumer use
bit 5,6 - reserved for system use (must be preserved)
bits 0-4 - reserved for server (must be preserved) */
BYTE sr_name[11]; /* pathname sought. Format:
0-3 character extension, left justified (in last 3 chars) */
BYTE sr_server[5]; /* available for server use (1st byte must be non-zero) */
BYTE sr_res[4]; /* reserved for consumer use */
A File Search request will terminate when either the
9Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 33 - November 7, 1988
requested maximum number of entries that match the named
file are found, or the end of directory is reached without
the maximum number of matches being found. A response con-
taining no entries indicates that no matching entries were
found between the starting point of the search and the end
of directory.
There may be multiple matching entries in response to a sin-
gle request as File Search supports "wild cards" in the file
name (last component of the pathname). The wild card match-
ing algorithm is described in the "Delete File" description.
Unprotected servers require the requester to have read per-
mission on the subtree containing the directory searched.
Protected servers require the requester to have read permis-
sion on the directory searched.
If a File Search requests more data than can be placed in a
message of the max-xmit-size for the TID specified, the
server will abort the virtual circuit to the consumer.
dir_info entries have the following format.
BYTE find_buf_reserved[21]; /* reserved (search_status) */
BYTE find_buf_attr; /* attribute */
WORD find_buf_time; /* modification time (hhhhh mmmmmm xxxxx)
where 'xxxxx' is in two second increments */
WORD find_buf_date; /* modification date (yyyyyyy mmmm ddddd) */
WORD find_buf_size_l; /* file size -- low word */
WORD find_buf_size_h; /* file size -- high word */
BYTE find_buf_pname[13]; /* file name -- ASCII (null terminated) */
File Search may generate the following errors:
Error Class ERRDOS:
ERRnofiles
Error Class ERRSRV:
ERRerror
ERRaccess
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 34 - November 7, 1988
_5._2_3. _C_r_e_a_t_e _P_r_i_n_t _F_i_l_e
8______________________________________________________________________
>From Consumer To Consumer
8______________________________________________________________________
smb_com SMBsplopen smb_com SMBsplopen
smb_wct 2 smb_wct 1
smb_vwv[0] length of printer setup data smb_vwv[0] file handle
smb_vwv[1] mode smb_bcc 0
smb_bcc min = 2
smb_buf ASCII -- 04
identifier string (max 15)
8______________________________________________________________________
7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|
This message is sent to create a new printer file. The file
handle returned can be used for subsequent write and close
commands. The file name will be formed by concatenating the
identifier string and a server generated number. The file
will be deleted once it has been printed.
The mode field can have the following values:
0 = Text mode. (DOS servers will expand TABs.)
1 = Graphics mode.
Protected servers grant write permission to the creator of
the file. No other users will be given any permissions to
the file. All users will have read permission to the print
queue, but only the print server has write permission to it.
Create Print File may generate the following errors:
Error Class ERRDOS:
ERRbadpath
ERRnofids
ERRnoaccess
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRqfull
ERRqtoobig
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 35 - November 7, 1988
_5._2_4. _C_l_o_s_e _P_r_i_n_t _F_i_l_e
8 __________________________________________________
>From Consumer To Consumer
8 __________________________________________________
smb_com SMBsplclose smb_com SMBsplclose
smb_wct 1 smb_wct 0
smb_vwv[0] file handle smb_bcc 0
smb_bcc 0
8 __________________________________________________
7 |7|7|7|7|7|
|7|7|7|7|7|
|7|7|7|7|7|
This message invalidates the specified file handle and
queues the file for printing. The file handle must refer-
ence a print file.
Close Print File may generate the following errors:
Error Class ERRDOS:
ERRbadfid
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvdevice
ERRqtoobig
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._2_5. _W_r_i_t_e _P_r_i_n_t _F_i_l_e
8 ____________________________________________________
>From Consumer To Consumer
8 ____________________________________________________
smb_com SMBsplwr smb_com SMBsplwr
smb_wct 1 smb_wct 0
smb_vwv[0] file handle smb_bcc 0
smb_bcc min = 4
smb_buf Data block -- 01
length of data
data
8 ____________________________________________________
7 |7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|
This message appends the data block to the print file speci-
fied by the file handle. The file handle must reference a
print file. The first block sent to a print file must con-
tain the printer setup data. The length of this data is
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 36 - November 7, 1988
specified in the Create Print File request.
If a Write Print File sends a message of length greater than
the max-xmit-size for the TID specified, the server will
abort the virtual circuit to the consumer.
Write Print File may generate the following errors:
Error Class ERRDOS:
ERRbadfid
ERRnoaccess
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvdevice
ERRqtoobig
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_5._2_6. _G_e_t _P_r_i_n_t _Q_u_e_u_e
8 __________________________________________________________
>From Consumer To Consumer
8 __________________________________________________________
smb_com SMBsplretq smb_com SMBsplretq
smb_wct 2 smb_wct 2
smb_vwv[0] max_count smb_vwv[0] count
smb_vwv[1] start index smb_vwv[1] restart index
smb_bcc 0 smb_bcc min = 3
smb_buf Data block -- 01
length of data
queue elements
8 __________________________________________________________
7 |7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|
This message obtains a list of the elements currently in the
print queue on the server. "start index" specifies the
first entry in the queue to return, "max_count" specifies
the maximum number of entries to return, this may be a posi-
tive or negative number. A positive number requests a for-
ward search, a negative number indicates a backward search.
In the response "count" indicates how many entries were
actually returned. "Restart index" is the index of the entry
following the last entry returned; it may be used as the
start index in a subsequent request to resume the queue
listing.
9Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 37 - November 7, 1988
Get Print Queue will return less than the requested number
of elements only when the top or end of the queue is encoun-
tered
The format of the queue elements returned is:
smb_date WORD file date (yyyyyyy mmmm ddddd)
smb_time WORD file time (hhhhh mmmmmm xxxxx)
where 'xxxxx' is in 2 second increments
smb_status BYTE entry status
01 = held or stopped
02 = printing
03 = awaiting print
04 = in intercept
05 = file had error
06 = printer error
07-FF = reserved
smb_file WORD spool file number (from create print file request)
smb_sizelo WORD low word of file size
smb_sizehi WORD high word of file size
smb_res BYTE reserved
smb_name BYTE[16] originator name (from create print file request)
Get Print Queue may generate the following errors:
Error Class ERRDOS:
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRqeof
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 38 - November 7, 1988
_6. _M_e_s_s_a_g_e _C_o_m_m_a_n_d_s
These commands provide a message delivery system between
users of systems participating in the network. The message
commands cannot use VCs established for the file sharing
commands. A separate VC, dedicated to messaging, must be
established.
Messaging services should support message forwarding. By
convention user names used for message delivery have a suf-
fix (in byte 16) of "03", forwarded names have a suffix of
"05". The algorithm for sending messages is to first attempt
to deliver the message to the forwarded name, and only if
this fails to attempt to deliver to the normal name.
_6._1. _S_e_n_d _S_i_n_g_l_e _B_l_o_c_k _M_e_s_s_a_g_e
8__________________________________________________________________
>From Consumer To Consumer
8__________________________________________________________________
smb_com SMBsends smb_com SMBsends
smb_wct 0 smb_wct 0
smb_bcc min = 7 smb_bcc 0
smb_buf[] ASCII -- 04
originator name (max 15 bytes)
ASCII -- 04
destination name (max 15 bytes)
Data Block -- 01
length of message (max 128)
message (max 128 bytes)
8__________________________________________________________________
7|7|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|7|
Send Single Block Message sends a short message (up to 128
bytes in length) to a single destination (user).
The names specified in this message do not include the one
byte suffix ("03" or "05").
Send Single Block Message may generate the following errors.
Error Class ERRDOS:
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvnid
ERRpaused
ERRmsgoff
ERRnoroom
<implementation specific>
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 39 - November 7, 1988
Error Class ERRHRD:
<implementation specific>
_6._2. _S_e_n_d _B_r_o_a_d_c_a_s_t _M_e_s_s_a_g_e
8_____________________________________________________________
>From Consumer To Consumer
8_____________________________________________________________
smb_com SMBsendb No Response
smb_wct 0
smb_bcc min = 8
smb_buf[] ASCII -- 04
originator name (max 15 bytes)
ASCII -- 04
"*"
Data Block -- 01
length of message (max 128)
message (max 128 bytes)
8_____________________________________________________________
7|7|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|7|7|7|
Send Broadcast Message sends a short message (up to 128
bytes in length) to every user in the network.
The name specified in this message does not include the one
byte suffix ("03").
There is no response message to this command, thus Send
Broadcast Message cannot generate errors.
_6._3. _S_e_n_d _S_t_a_r_t _o_f _M_u_l_t_i-_b_l_o_c_k _M_e_s_s_a_g_e
8__________________________________________________________________________
>From Consumer To Consumer
8__________________________________________________________________________
smb_com SMBsendstrt smb_com SMBsendstrt
smb_wct 0 smb_wct 1
smb_bcc min = 0 smb_vwv message group ID
smb_buf[] ASCII -- 04 smb_bcc 0
originator name (max 15 bytes)
ASCII -- 04
destination name (max 15 bytes)
8__________________________________________________________________________
7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|
This command informs the server that a multi-block message
will be sent. The server returns a message group ID to be
used to identify the message blocks when they are sent.
The names specified in this message do not include the one
byte suffix ("03" or "05").
Send Start of Multi-block Message may generate the following
errors.
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 40 - November 7, 1988
Error Class ERRDOS:
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvnid
ERRpaused
ERRmsgoff
ERRnoroom
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_6._4. _S_e_n_d _T_e_x_t _o_f _M_u_l_t_i-_b_l_o_c_k _M_e_s_s_a_g_e
8________________________________________________________________
>From Consumer To Consumer
8________________________________________________________________
smb_com SMBsendtxt smb_com SMBsendtxt
smb_wct 1 smb_wct 0
smb_vwv message group ID smb_bcc 0
smb_bcc min = 3
smb_buf[] Data Block -- 01
length of message (max 128)
message (max 128 bytes)
8________________________________________________________________
7|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|
|7|7|7|7|7|7|7|7|
This command delivers a segment of a multi-block message to
the server. It must contain a valid message group ID
returned by an earlier Start Multi-block Message command.
A maximum of 128 bytes of message may be sent with this com-
mand. A multi-block message cannot exceed 1600 bytes in
total length (sum of all segments sent with a given message
group ID).
Send Text of Multi-block Message may generate the following
errors.
Error Class ERRDOS:
<implementation specific>
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 41 - November 7, 1988
Error Class ERRSRV:
ERRerror
ERRinvnid
ERRpaused
ERRmsgoff
ERRnoroom
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_6._5. _S_e_n_d _E_n_d _o_f _M_u_l_t_i-_b_l_o_c_k _M_e_s_s_a_g_e
8 ___________________________________________________
>From Consumer To Consumer
8 ___________________________________________________
smb_com SMBsendend smb_com SMBsendend
smb_wct 0 smb_wct 0
smb_vwv message group ID smb_bcc 0
smb_bcc 0
8 ___________________________________________________
7 |7|7|7|7|7|
|7|7|7|7|7|
|7|7|7|7|7|
This command signals the completion of the multi-block mes-
sage identified by the message group ID.
Send End of Multi-block Message may generate the following
errors.
Error Class ERRDOS:
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvnid
ERRpaused
ERRmsgoff
<implementation specific>
Error Class ERRHRD:
<implementation specific>
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 42 - November 7, 1988
_6._6. _F_o_r_w_a_r_d _U_s_e_r _N_a_m_e
8__________________________________________________________________
>From Consumer To Consumer
8__________________________________________________________________
smb_com SMBfwdname smb_com SMBfwdname
smb_wct 0 smb_wct 0
smb_bcc min = 2 smb_bcc 0
smb_buf[] ASCII -- 04
forwarded name (max 15 bytes)
8__________________________________________________________________
7|7|7|7|7|7|7|
|7|7|7|7|7|7|
|7|7|7|7|7|7|
This command informs the server that it should accept mes-
sages sent to the forwarded name.
The name specified in this message does not include the one
byte suffix ("03" or "05").
Forward User Name may generate the following errors.
Error Class ERRDOS:
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvnid
ERRrmuns
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_6._7. _C_a_n_c_e_l _F_o_r_w_a_r_d
8__________________________________________________________________
>From Consumer To Consumer
8__________________________________________________________________
smb_com SMBcancelf smb_com SMBcancelf
smb_wct 0 smb_wct 0
smb_bcc min = 2 smb_bcc 0
smb_buf[] ASCII -- 04
forwarded name (max 15 bytes)
8__________________________________________________________________
7|7|7|7|7|7|7|
|7|7|7|7|7|7|
|7|7|7|7|7|7|
The Cancel Forward command cancels the effect of a prior
Forward User Name command. The addressed server will no
longer accept messages for the designated user name.
The name specified in this message does not include the one
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 43 - November 7, 1988
byte suffix ("05").
Cancel Forward may generate the following errors.
Error Class ERRDOS:
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvnid
<implementation specific>
Error Class ERRHRD:
<implementation specific>
_6._8. _G_e_t _M_a_c_h_i_n_e _N_a_m_e
8_______________________________________________________________
>From Consumer To Consumer
8_______________________________________________________________
smb_com SMBgetmac smb_com SMBgetmac
smb_wct 0 smb_wct 0
smb_bcc 0 smb_bcc min = 2
smb_buf[] ASCII -- 04
machine name (max 15 bytes)
8_______________________________________________________________
7|7|7|7|7|7|7|
|7|7|7|7|7|7|
|7|7|7|7|7|7|
The Get Machine Name command obtains the machine name of the
target machine. It is used prior to the Cancel Forward com-
mand to determine which machine to send the Cancel Forward
command to. Get Machine Name is sent to the forwarded name
to be canceled, and the server then returns the machine name
to which the Cancel Forward command must be sent.
Get Machine Name may return the following errors.
Error Class ERRDOS:
<implementation specific>
Error Class ERRSRV:
ERRerror
ERRinvnid
<implementation specific>
9
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 44 - November 7, 1988
Error Class ERRHRD:
<implementation specific>
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 45 - November 7, 1988
_7. _D_a_t_a _D_e_f_i_n_i_t_i_o_n_s
_7._1. _M_e_s_s_a_g_e _O_b_j_e_c_t_s
attribute:The attributes of the file. Portions of this
field indicate the type of file. The rest of the con-
tents are server specific. The MS-DOS server will
return the following values in attribute (bit0 is the
low order bit):
Generic Attributes:
bit4 - directory
MS-DOS Attributes:
bit0 - read only file
bit1 - "hidden" file
bit2 - system file
bit3 - volume id
bit5 - archive file
bits6-15 - reserved
Support of the Generic Attributes is mandatory; support
of the MS-DOS Attributes is optional. If the MS-DOS
Attributes are not supported, attempts to set them must
be rejected and atempts to match on them (e.g., File
Search) must result in a null response.
count of bytes:The count of bytes (1 to the maximum size)
read/written. The maximum size is server specific.
count left:The count of bytes not yet read/written. This
field is advisory only and is used for read-ahead in
the server.
count-returned:The actual number of directory entries that
are returned by a file-search response.
data read/written:The actual data.
dialect-0-dialect-n:A list of dialects, each of which iden-
tifies a requested protocol and version in a string.
Examples: "SNA-REV2" "TEST PROTOCOL" "RING.2"
dir_info:A data block containing an array of directory
entries returned by file search.
dir pathname:An ASCII string, null terminated, that defines
the location of a file within the tree. Use the '\'
character to separate components. The last component
names a directory. The maximum size of this field is
server specific. The pathname is relative to a TID and
may or may not commence with a '\'
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 46 - November 7, 1988
file handle:The file identifier obtained form an open,
create, make new file, and make temp file. File han-
dles are unique within a process id.
file pathname:An ASCII string, null terminated, that defines
the location of a file within the tree. Use the '\'
character to separate components. The last component
names a file. The maximum size of this field is server
specific. The pathname is relative to a TID and may or
may not commence with a '\'
file size low/hi:Low and hi words of a 32-bit long field
that represents the Data file size.
identifier string:The "originator name" of the owner of a
print file. The server will add a number to it to gen-
erate a unique file name. This is a null terminated
ASCII string.
max-count:The maximum number of directory entries that can
be returned by a file-search response.
max xmit size:The maximum size message that a server can
handle.
message group IDA message group ID uniquely identifies a
multi-block message.
non-owner access:The access rights of other than the owner.
offset low/hi:The low and hi words of a 32-bit offset.
owner access:The access rights of the owner.
owner id:The user id of the owner of the file.
password:May be used with the pathname for authentication by
the NET USE command. This is a null terminated ASCII
string.
r/w/share:This field defines the file mode. It contains
fields that represent the following:
Access modes:
Read
Write
Read/Write
Sharing modes:
Exclusive
No restriction
Multiple Readers
Multiple Writers
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 47 - November 7, 1988
search-status:A variable block reserved for server specific
information that is passed from each file search
response message to the next file search request.
time1 low/hi:File modification time. these two words define
a 32 bit field that contains the modification time
expressed as seconds past Jan 1 1970 (local time zone).
A value of zero indicates a null time field.
_7._2. _D_a_t_a _B_u_f_f_e_r _F_o_r_m_a_t_s (_s_m_b__b_u_f)
The data portion of these messages typically contains the
data to be read or written, file paths, or directory paths.
The format of the data portion depends on the message. All
fields in the data portion have the same format. In every
case it consists of an identifier byte followed by the data.
8 _______________________________________________________
Data Identifier Bytes
8 _______________________________________________________
Name Description Value
8 _______________________________________________________
Data Block See Below 01
Dialect Null terminated ASCII String 02
Pathname Null terminated ASCII String 03
ASCII Null terminated ASCII String 04
Variable block See Below 05
8 _______________________________________________________
7 |8|7|7|7|7|7|7|7|
9 |7|7|7|7|7|7|
|7|7|7|7|7|7|
|8|7|7|7|7|7|7|7|
9When the identifier indicates a data block or variable block
then the format is a word indicating the length followed by
the data. ASCII strings are null terminated.
Despite the flexible encoding scheme, no field of a data
portion may be omitted or included out of order. In addi-
tion, neither an smb_wct nor smb_bcc of value 0 at the end
of a message may be omitted.
_7._3. _C_o_m_m_a_n_d _C_o_d_e_s
The following values have been assigned for the protocol
commands.
#define SMBmkdir 0x00 /* create directory */
#define SMBrmdir 0x01 /* delete directory */
#define SMBopen 0x02 /* open file */
#define SMBcreate 0x03 /* create file */
#define SMBclose 0x04 /* close file */
#define SMBflush 0x05 /* flush file */
#define SMBunlink 0x06 /* delete file */
#define SMBmv 0x07 /* rename file */
#define SMBgetatr 0x08 /* get file attributes */
#define SMBsetatr 0x09 /* set file attributes */
#define SMBread 0x0A /* read from file */
#define SMBwrite 0x0B /* write to file */
#define SMBlock 0x0C /* lock byte range */
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 48 - November 7, 1988
#define SMBunlock 0x0D /* unlock byte range */
#define SMBctemp 0x0E /* create temporary file */
#define SMBmknew 0x0F /* make new file */
#define SMBchkpth 0x10 /* check directory path */
#define SMBexit 0x11 /* process exit */
#define SMBlseek 0x12 /* seek */
#define SMBtcon 0x70 /* tree connect */
#define SMBtdis 0x71 /* tree disconnect */
#define SMBnegprot 0x72 /* negotiate protocol */
#define SMBdskattr 0x80 /* get disk attributes */
#define SMBsearch 0x81 /* search directory */
#define SMBsplopen 0xC0 /* open print spool file */
#define SMBsplwr 0xC1 /* write to print spool file */
#define SMBsplclose 0xC2 /* close print spool file */
#define SMBsplretq 0xC3 /* return print queue */
#define SMBsends 0xD0 /* send single block message */
#define SMBsendb 0xD1 /* send broadcast message */
#define SMBfwdname 0xD2 /* forward user name */
#define SMBcancelf 0xD3 /* cancel forward */
#define SMBgetmac 0xD4 /* get machine name */
#define SMBsendstrt 0xD5 /* send start of multi-block message */
#define SMBsendend 0xD6 /* send end of multi-block message */
#define SMBsendtxt 0xD7 /* send text of multi-block message */
_7._4. _E_r_r_o_r _C_o_d_e_s _a_n_d _C_l_a_s_s_e_s
_E_R_R_O_R _C_L_A_S_S _C_O_D_E_S
SUCCESS 0The request was successful.
ERRDOS 0x01Error is generated by the server operating system.
ERRSRV 0x02Error is generated by the server network file manager.
ERRHRD 0x03Error is an hardware error (MS-DOS int 24).
ERRCMD 0xFFCommand was not in the "SMB" format. (optional)
The following error codes may be generated with the SUCCESS
error class.
SUCCESS 0 The request was successful.
BUFFERED 0x54 message has been buffered
LOGGED 0x55 message has been logged
DISPLAYED 0x56 user message displayed
The following error codes may be generated with the ERRDOS
error class. The XENIX errors equivalent to each of these
errors are noted at the end of the error description.
ERRbadfunc 1
7 Invalid function. The server OS did not recognize or could not perform
a system call generated by the server, e.g., set the DIRECTORY attribute
on a data file, invalid seek mode. [EINVAL]
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 49 - November 7, 1988
ERRbadfile 2
7 File not found. The last component of a file's pathname could not be
found. [ENOENT]
ERRbadpath 3
7 Directory invalid. A directory component in a pathname could not be
found. [ENOENT]
ERRnofids 4
7 Too many open files. The server has no file handles (fids) available.
[EMFILE]
ERRnoaccess 5
7 Access denied, the requester's context does not permit the requested
function. This includes the following conditions. [EPERM]
9 duplicate name errors
invalid rename command
write to fid open for read only
read on fid open for write only
attempt to open read-only file for write
attempt to delete read-only file
attempt to set attributes of a read only file
attempt to create a file on a full server
directory full
attempt to delete a non-empty directory
invalid file type (e.g., file commands on a directory)
9ERRbadfid 6
7 Invalid file handle. The file handle specified was not recognized by
the server. [EBADF]
ERRbadmcb 7Memory control blocks destroyed. [EREMOTEIO]
ERRnomem 8Insufficient server memory to perform the requested function. [ENOMEM]
ERRbadmem 9Invalid memory block address. [EFAULT]
ERRbadenv 10Invalid environment. [EREMOTEIO]
ERRbadformat 11Invalid format. [EREMOTEIO]
ERRbadaccess 12Invalid open mode.
ERRbaddata 13Invalid data (generated only by IOCTL calls within the server). [E2BIG]
ERR 14reserved
ERRbaddrive 15Invalid drive specified. [ENXIO]
ERRremcd 16
7 A Delete Directory request attempted to remove the server's current
directory. [EREMOTEIO]
ERRdiffdevice17Not same device (e.g., a cross volume rename was attempted) [EXDEV]
ERRnofiles 18
7 A File Search command can find no more files matching the specified cri-
teria.
ERRbadshare 32
7 The sharing mode specified for a non-compatibility mode Open conflicts
with existing FIDs on the file. [ETXTBSY]
ERRlock 33
7 A Lock request conflicted with an existing lock or specified an invalid
mode, or an Unlock request attempted to remove a lock held by another
process. [EDEADLOCK]
ERRfilexists 80
7 The file named in a Create Directory or Make New File request already
exists. The error may also be generated in the Create and Rename tran-
sactions. [EEXIST]
The following error codes may be generated with the ERRSRV
error class.
ERRerror 1Non-specific error code. It is returned under the following conditions:
9 resource other than disk space exhausted (e.g., TIDs)
first command on VC was not negotiate
multiple negotiates attempted
internal server error [ENFILE]
9Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 50 - November 7, 1988
ERRbadpw 2Bad password - name/password pair in a Tree Connect is invalid.
ERRbadtype 3reserved
ERRaccess 4
7 The requester does not have the necessary access rights within the
specified TID context for the requested function. [EACCES]
ERRinvnid 5The tree ID (tid) specified in a command was invalid.
ERRinvnetname 6Invalid name supplied with tree connect.
ERRinvdevice 7
7 Invalid device - printer request made to non-printer connection or non-
printer request made to printer connection.
ERRqfull 49Print queue full (files) -- returned by open print file.
ERRqtoobig 50Print queue full -- no space.
ERRqeof 51EOF on print queue dump.
ERRinvpfid 52Invalid print file FID.
ERRpaused 81Server is paused.
ERRmsgoff 82Not receiving messages.
ERRnoroom 83No room to buffer message.
ERRrmuns 87Too many remote user names.
ERRnosupport 0xFFFFFunction not supported.
The following error codes may be generated with the ERRHRD
error class. The XENIX errors equivalent to each of these
errors are noted at the end of the error description.
ERRnowrite 19Attempt to write on write-protected diskette. [EROFS]
ERRbadunit 20Unknown unit. [ENODEV]
ERRnotready 21Drive not ready. [EUCLEAN]
ERRbadcmd 22Invalid disk command.
ERRdata 23Data error (CRC). [EIO]
ERRbadreq 24Bad request structure length. [ERANGE]
ERRseek 25Seek error.
ERRbadmedia 26Unknown media type.
ERRbadsector27Sector not found.
ERRnopaper 28Printer out of paper.
ERRwrite 29Write fault.
ERRread 30Read fault.
ERRgeneral 31General failure.
ERRbadshare 32
7 A compatibility mode open conflicts with an existing
open on the file. [ETXTBSY]
_8. _E_x_c_e_p_t_i_o_n _H_a_n_d_l_i_n_g
Exception handling is built upon the various environments
supported by the file sharing protocol (see ARCHITECTURAL
MODEL section). When any environment is dissolved (in either
an orderly or disorderly fashion) all contained environments
are dissolved. The hierarchy of environments is summarized
below:
Virtual Circuit
TID
PID
FID
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 51 - November 7, 1988
As can be seen from this summary, the Virtual Circuit (VC)
is the key environment. When a VC is dissolved the server
processes (or equivalent) are terminated; the TIDs, PIDs and
FIDs are invalidated, and any outstanding request is dropped
-- a response will not be generated.
The termination of a PID will close all FIDs it contains.
The destruction of TIDs and FIDs has no affect on other
environments.
If the server receives a message with a bad format, e.g.,
lacks the "FFSMB" header, it may abort the VC.
If a server is unable to deliver responses to a consumer
within n seconds, it considers the consumer dead and drops
the VC to it (we anticipate that n will be a function of the
transport round trip delay time).
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 52 - November 7, 1988
_A_p_p_e_n_d_i_x _A - _A_n _E_x_a_m_p_l_e
In this example a MS-DOS machine will access a file on a
remote machine that is running a server that supports MS-DOS
file sharing.
STEP 1: Using protocols described elsewhere, the MS-DOS
machine has obtained a virtual circuit (VC) to the server on
the remote machine. The MS-DOS machine will then generate
"Negotiate Message" on the VC with a dialect field that con-
tains "PC NETWORK PROGRAM 1.0". The remote server will
respond with a "Negotiate Reply Message" which will contain
the index of the dialect string that contained "PC NETWORK
PROGRAM 1.0", in this case 1, which indicates that it will
service that protocol.
STEP 2: The MS-DOS machine now generates a "Tree Connect
Message" with a pathname and a password. The remote server
will respond with a "Tree Connect Response Message" indicat-
ing that the password has been validated permitting access
to the associated sub-tree. A "Tree ID" is returned for
future use.
STEP 3: The MS-DOS machine wishes to open and read a file on
the remote server. This would be in response to a program
that referenced a file on that remote system. The MS-DOS
machine will generate, in response to a user program open,
an "Open Message" with the "file path" of the file to be
opened along with the mode information and the tree id. The
file-path must not contain the path specified in the tree
connect message. The server will respond with a "Open Reply
Message" which will contain a file handle for use with
future messages. It will also return the file size and
modification time.
STEP 4: The MS-DOS machine now reads the file, in response
to user program file reads. It will generate a "Read Mes-
sage" with the "file handle" obtained from the "open mes-
sage". The message will contain a count of bytes to be read
and an offset within the file to start reading, and possibly
count indicating future requests. The server will respond
with a "Read Reply Message" with the count of data read and
the data.
STEP 5: Some number of "Read Messages" and possibly "Write
Messages" are transmitted, and eventually the file is closed
by the user process. The MS-DOS machine will generate a
"Close Message" which contains the "file handle" obtained
from the "Open Response Message" and a new modification
time. The server responds with a "Close Response Message".
STEP 6: At some time the MS-DOS machine generates a "Tree
Disconnect Message" and receives a "Tree Disconnect Response
Message." At this point the VC may be de-allocated.
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446
File Sharing Protocol - 53 - November 7, 1988
Copyright Microsoft Corp., 1987, 1988November 30, 1990 INTEL PN 138446