Skip to content

Expose atomic rename through Workspace.fs #120

Description

@abhinavgautam01

Description

packages/dofs/src/fs/rename.ts already implements transactional file, directory and symbolic-link moves. It handles destination replacement, non-empty directories, read-only mounts, symbolic-link parents, change tombstones, revision stamping, cache invalidation and directory subtree tracking.

That operation is not available through WorkspaceFilesystem or WorkspaceFilesystemStub. Callers of Workspace.fs must copy the source and then delete it. The Worker shell uses this fallback for mv, so a failure between the copy and delete can leave both paths or a partially copied directory.

Expose the existing primitive as:

rename(oldPath: string, newPath: string): Promise<void>;

The public filesystem operation runs against the durable object's local store, so it should be mirrored through the Workers RPC WorkspaceFilesystemStub. It does not need a new method on the durable object to computerd Cap'n Web WorkspaceRPC; the existing synchronization protocol can propagate the resulting live entries and tombstones.

Expected outcome

  • Add rename to WorkspaceFilesystem.
  • Mirror it on WorkspaceFilesystemStub with the normal filesystem observation span.
  • Update the Worker shell filesystem interface and make mv call rename instead of copy and delete.
  • Document overwrite behavior and errors such as ENOENT, ENOTEMPTY, EISDIR, ENOTDIR, EINVAL and EROFS.
  • Add public-surface and Workers RPC tests in addition to the existing provider-level rename coverage.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions