volumes::stat

Tag 4: a client names a volume from its listing; the server sends exactly one response carrying the volume as the listing reports it, its bytes in use and the hash of its content, or an error, and the scope finishes.

A client opens the scope with a request whose payload is the tag byte 4 followed by the name of a volume. The server sends exactly one response, which is the volume examined, a refusal, or an error. The response finish follows the response, and no frame follows the finish.

The request. The request carries the name of one volume. Request states its form.
The volume named. The client names a volume by the name its volumes::list listing gave it. The server resolves the name against the identity under which the connection was authorized, as Authorization provides. A name that is not in the client’s listing is answered with an error. A client cannot name another client’s volume.
The answer. The answer carries the four fields the listing reports for the volume, and two more: the number of bytes in use and the hash of the content. Response states its form.
At the time of the response. The bytes in use and the hash are those of the volume at the time of the response. No frame of this specification reports a change in either; a client that needs the current values sends another request.
A held volume is not examined. The server does not examine a volume that a running container of the client holds, that a volumes::fuse_serve of the client holds, or that is under a volumes::stat, volumes::read, volumes::write, volumes::filetree, volumes::edit or volumes::delete, at the time of the request. A request naming such a volume is answered with the refusal the response states for who holds it — Mounted, FuseServed or Held — decided in the order Capabilities states for an operation, and nothing is changed. The server holds the volume to itself from the moment it accepts the request until the response finish, and a run, a FUSE serve or another operation naming the volume is refused for as long as it does.
The error. An error states that the volume was not examined, and that nothing was determined about it. A volume absent from the client’s listing is answered with an error. A volume that something holds is answered with the refusal the response states, which is not an error.
No volume at all. A server that holds out none of the three mode objects of Capabilities keeps no volume and answers every request of this endpoint with exactly one response, the byte 4 alone, and the response finish, before anything is looked up. Every other requirement of this page holds for a server that keeps volumes.

In this section

Request — The payload is the tag byte 4 followed by the name of the volume as a varint length and UTF-8 bytes, in the postcard wire format.
Response — The server sends exactly one response, whose payload begins with the byte 0 followed by the stat in the postcard wire format; is the byte 1, 2 or 3 alone when a running container, a FUSE serve or an operation holds the volume; is the byte 4 alone when the server keeps no volume; or begins with the byte 5 followed by an error as one JSON value; and the response finish follows it.