FUSE rename

Tag 4: the client renames an entry within the volume, by the path of the entry within the volume, in the form the FUSE mount ask of the same tag has on the container proxy; the server answers with exactly one channel response, ok, read only, or an error, from the volume.

The client opens this channel to perform on the served volume what a program in a container performs on a FUSE mount. The ask names the entry by its path within the volume, and names no volume: the scope is the volume. It is, byte for byte, the ask of tag 4 a FUSE mount’s scope carries on the container proxy, and the server answers it as a client answers that ask, from the volume.

  • The request. The tag byte 4 followed by the ask. Request states its form.
  • The response. Exactly one channel response and the channel response finish. Response states the sequence.
  • The meaning. What the ask means, and what its answer means, FUSE rename states for the mount, and FUSE rename states for the relay; the same holds here, the volume standing where the client’s storage stands there.
  • The volume answers. The server answers from the volume as it is at the time of the answer, and changes the volume as the ask asks before it answers ok. Nothing is buffered on the client’s behalf.
  • The mode. A persistent volume takes the change in place. An ephemeral volume takes it into the layer of this FUSE serve, and answers with an error a change that would take the layer past overlay_disk, the volume and the layer as they were. A read_only volume answers this ask with the read-only byte, and is not changed.