Module plan 

What to do to bring a folder and a store into step – decided from three views of every path: as both sides were when they last agreed (the base), as the store is now, as the folder is now. Pure: no I/O, so every case is tested.

A change on one side is carried to the other. A change on both sides is a conflict: the server’s version wins the name, the local one is kept beside it as a copy – never merged, never lost (the copy is uploaded in the next round). A deletion never takes a change of the other side with it: a file deleted here but changed on the server comes back, a file deleted on the server but changed here is uploaded again.

A move is carried over as a move – what was moved keeps its node on the server (its versions, its shares) and is not sent again. On the server a move is told by the node’s id at another path; here by the file’s id on the file system (its inode) at another path, the size and modification time unchanged. A move that cannot be one – onto a path taken on the other side, into or out of a vault (RFC 0006, 6), a file system without file ids (OPEN: Windows) – is a deletion and a creation.

Structs

Base

A path as both sides were when they last agreed.

Local

A file or directory of the folder at a path.

Remote

A node of the store at a path.

Enums

Action

Functions

parent

The parent of a path; "" at the top.

plan

The actions in the order they must run: moves here first, local directories and copies, then downloads; remote directories shallow before deep, moves on the server, then uploads; deletions deep before shallow.

rename

Moves a path and what is below it to another path in a map.

vault_at

The vault a path of the store lies in: that of its nearest ancestor known.

Type Aliases

RelPath

A path relative to the folder, /-separated, without a leading / (Projects/plan.txt).