You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make the fork adapter the owner of its metadata containers and let a same-host-path
peer follow them, so an AFP+EtherDFS/SMB pair sharing one host path stays
metadata-consistent across a rename/delete.
- New optional fs.ForkContainers{ MetadataPaths(storePath) []string }: the
AppleDouble base returns its single sidecar path (whatever layout placed it);
ads/xattr/nofork keep metadata with the file and return nil (don't implement it).
shareFS forwards the capability. shareFS.Rename/Remove already delegate the
container move/delete to the adapter (MoveMetadata/DeleteMetadata) — the adapter
owns what its containers are; docs clarified.
- share.Reactor coordination: NamedPath gains an optional FS fs.ForkFS field (AFP/
SMB/NCP set it from v.FS()/sh.FS()). On a foreign OpRename under a shared root,
Reactor.coordinate re-derives the new name's shortname via fs.Named so the peer's
NameEngine mapping is fresh and stable; MetadataPathsFor(np, hostPath) surfaces the
sidecars the peer must re-stat (host->store conversion + ForkContainers) for the
deferred wire-push slice.
Wire push (AFP attention / SMB CHANGE_NOTIFY) stays DEFERRED — this lands the
in-memory metadata + shortname consistency and the seam the push will consume.
Tests: fork_containers_test.go (capability present on appledouble per layout,
absent/nil for ride-with-file adapters, forwarded through shareFS);
reactor_coord_test.go (MetadataPathsFor host->store + outside/no-FS nil; coordinate
re-derives a stable 8.3 shortname on foreign rename; nil-FS no-op).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
0 commit comments