Treat a placeholder as the photograph, not as a one-byte file
The folder connector was pointed at a Nextcloud VFS tree and got three things wrong, the first of which loses work. **A dehydrated sidecar read as absent.** `a.drsc` does not exist when the client has dehydrated it — only `a.drsc.nextcloud` does — so `get` missed, `.ok()` swallowed the `NotFound`, and the sidecar writer took that for "there is no sidecar yet" and wrote a fresh document over the existing one. Every edit another device had put there went with it. That function's own doc comment calls this the exact loss the format's unknown-key preservation exists to prevent. **A stub was catalogued as a 1-byte image**, and ARCH §9.0 measured this machine at 121,785 placeholders against 10,267 real files — so a folder library on a synced tree was ~92% broken rows. **Identity changed on hydration**, so downloading a photograph looked like a delete and an add, orphaning its thumbnail and its face rows. Entries now carry the photograph's own name and a `materialised` flag; `get` on a stub returns the new `RemoteError::NotMaterialised`, which is distinct from `NotFound` precisely because the sidecar writer must treat them differently — it fetches the sidecar and merges, or leaves the entry queued. Hydration is a **borrow**. `BorrowPool` records what was on disk before it asked, so `release_all` dehydrates only what a pass brought and leaves what the user already had. Reference counted: the thumbnail pass and the face pass meet on the same RAW, and without counting the first to finish dehydrates the file the second is reading. A borrow against a plain folder or a server does nothing, so a pass written for VFS runs everywhere. Releasing means asking the client to dehydrate and never deleting: a deletion inside a synced tree propagates to the server and removes the photograph from every device. Not a second backend — the capability is per *connection*, not per type, since the same folder hydrates only while the client runs. The convention arrives through a detector the registry supplies, so `dr-sync-folder` still knows nothing about any client's protocol. ARCH §9.0a records this as an amendment: finding 3 rejected hydration because it costs 100× a range read, and that comparison assumed a connector was available. A folder library has none.
This commit is contained in:
@@ -38,6 +38,50 @@ pub struct ChunkConstraints {
|
||||
pub max_chunks: u32,
|
||||
}
|
||||
|
||||
/// TRACES: FR-NC-6c
|
||||
/// Whether every listed object's content is actually reachable.
|
||||
///
|
||||
/// Every backend but a virtual-filesystem folder answers [`Always`](Self::Always).
|
||||
/// A VFS folder is the case this exists for: the sync client leaves a
|
||||
/// placeholder where a file is catalogued but not downloaded, so the name is
|
||||
/// listable and the bytes are not (ARCH §9.0).
|
||||
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
|
||||
pub enum Materialisation {
|
||||
/// Listing an object means its content can be read. Every server backend,
|
||||
/// and a plain directory.
|
||||
Always,
|
||||
|
||||
/// Some objects are placeholders, and nothing this process can do will
|
||||
/// change that — the sync client is not running, or the platform offers no
|
||||
/// way to ask. Such an object reads as
|
||||
/// [`RemoteError::NotMaterialised`](crate::RemoteError::NotMaterialised)
|
||||
/// and is shown as offline rather than broken.
|
||||
Placeholders,
|
||||
|
||||
/// Some objects are placeholders, and this backend can ask for their
|
||||
/// content — and give it back.
|
||||
///
|
||||
/// **Whole-file, and that is the whole difficulty.** Hydration has two
|
||||
/// states, one byte or all bytes, so using it to fill a grid transfers the
|
||||
/// entire library to produce thumbnails (ARCH §9.0). It belongs to the
|
||||
/// originals tier — an image opened in develop, exported, or deliberately
|
||||
/// pinned — and to passes the user has asked for and been quoted a price
|
||||
/// on. Never to browsing.
|
||||
OnDemand,
|
||||
}
|
||||
|
||||
impl Materialisation {
|
||||
/// Whether content can be fetched on request.
|
||||
pub fn can_materialise(self) -> bool {
|
||||
matches!(self, Materialisation::OnDemand)
|
||||
}
|
||||
|
||||
/// Whether some objects may have no content locally.
|
||||
pub fn has_placeholders(self) -> bool {
|
||||
!matches!(self, Materialisation::Always)
|
||||
}
|
||||
}
|
||||
|
||||
/// TRACES: FR-NC-3
|
||||
/// Whether the server can render thumbnails, and for what.
|
||||
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
|
||||
@@ -69,6 +113,8 @@ pub struct Capabilities {
|
||||
/// Conditional write (If-Match), for conflict-safe sidecar updates.
|
||||
pub conditional_write: bool,
|
||||
pub server_previews: ServerPreviews,
|
||||
/// Whether a listed object's content is necessarily present.
|
||||
pub materialisation: Materialisation,
|
||||
}
|
||||
|
||||
impl Capabilities {
|
||||
@@ -83,6 +129,9 @@ impl Capabilities {
|
||||
bulk_upload: false,
|
||||
conditional_write: false,
|
||||
server_previews: ServerPreviews::None,
|
||||
// The weakest backend still answers for everything it lists;
|
||||
// placeholders are a property a backend opts into.
|
||||
materialisation: Materialisation::Always,
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user