volumes::delete

Tag 13: a client names a volume from its listing; the server sends exactly one response stating that the volume no longer exists, that it is mounted and was not deleted, or an error, and the scope finishes; the deletion is not reversible.

A client opens the scope with a request whose payload is the tag byte 13 followed by the name of a volume. The server sends exactly one response, which states that the volume is deleted, that the volume is mounted and was not deleted, 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. A server may refuse to delete a volume that it offered on its own account and that the client did not create; the refusal is an error.
The deletion. When the server sends the byte 0, the volume no longer exists, and its content is gone. From that moment, every volumes::list scope the client opens omits the volume, and every list scope the client holds open that was sent the volume as added is sent it as removed: no listing the server sends as whole after the byte 0 contains it. The name then names no volume of the client, and every request naming it is answered with an error, until a volumes::create request by the client makes a new volume of that name. Deletion is not emptying: a client that wants an empty volume of the same name deletes the volume and creates one. Response states the form of the response.
One request. The request is the whole of the exchange. No frame precedes it, no confirmation follows it, and the deletion is not reversible.
A held volume is not deleted. When, at the time of the request, a running container of the client holds the volume, a volumes::fuse_serve of the client holds it, or it is under a volumes::stat, volumes::read, volumes::write, volumes::filetree, volumes::edit or another volumes::delete, the server does not delete it and answers with the refusal the response states for who holds it — Mounted, the byte 1; FuseServed, the byte 2; Held, the byte 3 — decided in the order Capabilities states for an operation. The volume, its content, and the client’s listing are as they were before the request. The server does not send the byte 0 for a volume anything holds at the time of the request.
The error. An error states that the server did not delete the volume, for a reason other than a hold. The volume remains in existence, its content is as it was, and the client’s listing shows it as before the request.
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 13 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 is exactly the byte 0 when the volume no longer exists; exactly the byte 1, 2 or 3 when a running container, a FUSE serve or an operation holds the volume and it was not deleted; exactly the byte 4 when the server keeps no volume; or the byte 5 followed by an error as one JSON value; and the response finish follows it.