ATTACH(5) File Formats Manual ATTACH(5)NAME
attach, session, nop - messages to initiate activity
SYNOPSIS
Tnop tag[2]
Rnop tag[2]
Tsession tag[2] chal[8]
Rsession tag[2] chal[8] authid[28] authdom[48]
Tattach tag[2] fid[2] uid[28] aname[28] ticket[72] auth[13]
Rattach tag[2] fid[2] qid[8] rauth[13]
DESCRIPTION
The nop request does nothing overt but may be used to synchronize the channel between two service hosts initially.
The session request is used to initialize a connection between a client and a server. All outstanding I/O on the connection is aborted.
The set of messages between session requests is called a session. The host's user name (authid) and its authentication domain (authdom)
identify the key to be used when authenticating to this host. The exchanged challenges (chal) are used in the authentication algorithm.
If authid is a null string no authentication is performed in this session.
The tag should be NOTAG (value 0xFFFF) for a nop or session message.
The attach message serves as a fresh introduction from a user on the client machine to a server. The message identifies the user (uid) and
may select the file tree to access (aname). The ticket and auth arguments contains authorization data derived from the exchanged chal-
lenges of the session message; see auth(6).
As a result of the attach transaction, the client will have a connection to the root directory of the desired file tree, represented by
fid. An error is returned if fid is already in use. The server's idea of the root of the file tree is represented by the returned qid.
ENTRY POINTS
An attach transaction will be generated for kernel devices (see intro(3)) when a system call evaluates a file name beginning with Pipe(2)
generates an attach on the kernel device pipe(3). The mount system call (see bind(2)) generates an attach messages to the remote file
server. When the kernel boots, an attach is made to the root device, root(3), and then an attach is made to the requested file server
machine.
SEE ALSO auth(6)ATTACH(5)
Check Out this Related Man Page
STAT(5) File Formats Manual STAT(5)NAME
stat, wstat - inquire or change file attributes
SYNOPSIS
Tstat tag[2] fid[2]
Rstat tag[2] fid[2] stat[116]
Twstat tag[2] fid[2] stat[116]
Rwstat tag[2] fid[2]
DESCRIPTION
The stat transaction inquires about the file identified by fid. The reply will contain a 116-byte (DIRLEN in <libc.h>) machine-independent
directory entry laid out as follows:
name[28] file name; must be / if the file is the root directory of the server
uid[28] owner name
gid[28] group name
qid.path[4] the file server's identification for the file
qid.vers[4] version number for given path
mode[4] permissions and flags
atime[4] last access time
mtime[4] last modification time
length[8] length of file in bytes
type[2] for kernel use
dev[2] for kernel use
Integers in this encoding are in little-endian order (least significant byte first). The convM2D and convD2M routines (see fcall(2)) con-
vert between directory entries and C structs.
This encoding may be turned into a machine dependent Dir structure (see stat(2)) using routines defined in fcall(2).
The mode contains permission bits as described in intro(5) and the following: 0x80000000 (this file is a directory), 0x40000000 (append
only), 0x20000000 (exclusive use). Writes to append-only files always place their data at the end of the file; the offset in the read or
write message is ignored, as is the OTRUNC bit in an open. Exclusive use files may be open for I/O by only one fid at a time across all
clients of the server. If a second open is attempted, it draws an error. Servers may implement a timeout on the lock on an exclusive use
file: if the fid holding the file open has been unused for an extended period (of order at least minutes), it is reasonable to break the
lock and deny the initial fid further I/O.
The two time fields are measured in seconds since the epoch (Jan 1 00:00 1970 GMT). The mtime field reflects the time of the last change
of content. For a plain file, mtime is the time of the most recent create, open with truncation, or write; for a directory it is the time
of the most recent remove, create, or wstat of a file in the directory. Similarly, the atime field records the last read of the contents;
also it is set whenever mtime is set. In addition, for a directory, it is set by an attach, walk, or create, all whether successful or
not.
The length records the number of bytes in the file. Directories and most files representing devices have a conventional length of 0.
The stat request requires no special permissions.
The wstat request can change some of the file status information. The name can be changed by anyone with write permission in the parent
directory; it is an error to change the name to that of an existing file. The mode and mtime can be changed by the owner of the file or
the group leader of the file's current group. The directory bit cannot be changed by a wstat; the other defined permission and mode bits
can. The gid can be changed: by the owner if also a member of the new group; or by the group leader of the file's current group if also
leader of the new group (see intro(5) for more information about permissions and users(6) for users and groups). None of the other data
can be altered by a wstat. In particular, there is no way to change the owner of a file.
A read of a directory yields an integral number of directory entries in the machine independent encoding given above (see read(5)).
ENTRY POINTS
Stat messages are generated by fstat and stat.
Wstat messages are generated by fwstat and wstat.
STAT(5)