Synced deletions move files into a per-session trash instead of unlinking them, when the sync lane is enabled.
Trash-on-delete is part of the directory-sync lane, gated on a remote flag that stays off if the lookup fails.
tengu_violin_wood Off in both readingsThe flag server returned off for the account this site reads and for the anonymous baseline. A reading of off cannot rule out a rollout these two readings sit outside of.
This account: off · anonymous baseline: off · compiled default in v2.1.239: on
Read once, for one account on one subscription tier, against v2.1.239. It isn't a statement about your account. What a flag value here can and cannot tell you
What's wrong with this entry?
When directory sync replays a deletion into the container, a file whose contents still match what both sides agreed on is moved into a per-session trash directory rather than removed outright. Files that changed locally are left alone. This is part of the directory-sync lane, which is gated on tengu_violin_wood and stays off if that lookup fails.
- The trash mirrors the original subtree, and a name collision gets a suffix; if no free name can be found the removal is abandoned.
- Files kept rather than trashed are recorded as
kept_changed,kept_unknown,mismatchorno_trash. - A rename across filesystems is refused rather than falling back to copy-and-delete.
- Failures are logged as
dir_sync_removal_failed.
no free name in the session trash
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.238
Sync state machine gains a moved-root case and a per-turn pull hook
Both mention directory
-
v2.1.238
Untracked-file survey extracted and shared
Both mention directory
-
v2.1.238
Sync internals reshaped around per-file credential state
Both mention directory