# FUSE rename

> Tag 4: the client renames an entry within the served subtree, by the path of the entry within the subtree, in the form the FUSE mount ask of the same tag has on a mount scope; the server answers with exactly one channel response, ok or an error, from the filesystem of the container.

Canonical: https://protocol.diverge.network/2.3.0/container-proxy-endpoints/filesystem-fuse-serve/client/rename/
Specification revision: 2.3.0

The client opens this channel to perform on the served subtree what a
program in a container performs on a FUSE mount: it is the last hop
of the [FUSE rename](/2.3.0/endpoints/containers-fuse-serve/client/rename/) channel of a
container FUSE serve. The ask names the entry by its path within the
subtree, and names no subtree: the scope is the subtree. It is, byte
for byte, the ask of tag `4` the server opens on a
[mount scope](/2.3.0/container-proxy-endpoints/fuse-mount/), going the other
way, and the server answers it from the filesystem of the container.

- **The request.** The tag byte `4` followed by the ask.
  [Request](/2.3.0/container-proxy-endpoints/filesystem-fuse-serve/client/rename/request/) states its form.
- **The response.** Exactly one channel response and the channel
  response finish. [Response](/2.3.0/container-proxy-endpoints/filesystem-fuse-serve/client/rename/response/) states the
  sequence.
- **The meaning.** What the ask means, and what its answer means,
  [FUSE rename](/2.3.0/container-proxy-endpoints/fuse-mount/server/rename/) states for the mount; the
  same holds here, the filesystem of the container standing where the
  client's storage stands there.
- **The filesystem answers.** The server answers from the filesystem
  of the container as it is at the time of the answer, and changes
  the container as the ask asks before it answers `ok`. A symbolic
  link is the link itself, a file. The server buffers nothing on the
  client's behalf.
- **No mode.** A container has no mode. Every change the server
  answers `ok` is in the container, where the program beside the
  proxy sees it; the read-only byte is never sent.
- **Left out.** Under `/proc`, `/sys` and `/dev` nothing is answered:
  a path there, or a path with a component `.` or `..`, is answered
  with an error, and the container is as it was.