GET /rest/config/folders on the depot server:
Android_apps | sendonly | /data/LT/BTSync/Android_apps
Android_dev_win | sendreceive | /data/LT/BTSync/Android_dev_win
Documentation | sendreceive | /data/LT/BTSync/Documentation
French_win | sendreceive | /data/LT/BTSync/French_win
Indonesian_win | sendreceive | /data/LT/BTSync/Indonesian_win
Win_everything_en | sendreceive | /data/LT/BTSync/Win_everything_en
CLAUDE.md states the invariant:
Server folders are Send Only; clients are receive-only.
Only Android_apps holds to it. The other five accept incoming changes.
Nothing is being corrupted today, because registration PATCHes defaults/folder to receive-only on the client, so a client built by our installer will not send. The exposure is that the master catalog's integrity depends entirely on every client staying correctly configured — one device that joined before that default was set, or one someone reconfigured by hand, can delete or overwrite files in the master copy, and Syncthing will propagate that to all the others. For a read-only distribution catalog on ~50 machines that is the wrong direction of trust: the server should refuse writes rather than rely on clients not attempting them.
Fix is per folder in the GUI (Folder → Edit → Advanced → Folder Type → Send Only), or over the API:
for f in Android_dev_win Documentation French_win Indonesian_win Win_everything_en; do
curl -s -X PATCH -H "X-API-Key: $KEY" \
-d '{"type":"sendonly"}' "http://127.0.0.1:8384/rest/config/folders/$f"
doneWorth doing after, not before, a look at whether anything has already been written back — a Send Only folder that has received changes shows "Local Additions" in the GUI and needs an explicit Revert.
Two follow-ups worth considering so this does not recur:
SETUP.md should say Send Only when it describes adding a catalog folder, since these were presumably added by hand.register.py could assert it rather than assume it. It already PATCHes each folder's device list in share_catalog_with(); the same call could set "type": "sendonly", which would make the invariant self-healing for every folder the reconciler touches. That is a behaviour change rather than a config fix, so raising it here rather than doing it.
Found while reading the config for #16.
GET /rest/config/folderson the depot server:CLAUDE.md states the invariant:
Only
Android_appsholds to it. The other five accept incoming changes.Nothing is being corrupted today, because registration PATCHes
defaults/folderto receive-only on the client, so a client built by our installer will not send. The exposure is that the master catalog's integrity depends entirely on every client staying correctly configured — one device that joined before that default was set, or one someone reconfigured by hand, can delete or overwrite files in the master copy, and Syncthing will propagate that to all the others. For a read-only distribution catalog on ~50 machines that is the wrong direction of trust: the server should refuse writes rather than rely on clients not attempting them.Fix is per folder in the GUI (Folder → Edit → Advanced → Folder Type → Send Only), or over the API:
Worth doing after, not before, a look at whether anything has already been written back — a Send Only folder that has received changes shows "Local Additions" in the GUI and needs an explicit Revert.
Two follow-ups worth considering so this does not recur:
SETUP.mdshould say Send Only when it describes adding a catalog folder, since these were presumably added by hand.register.pycould assert it rather than assume it. It already PATCHes each folder's device list inshare_catalog_with(); the same call could set"type": "sendonly", which would make the invariant self-healing for every folder the reconciler touches. That is a behaviour change rather than a config fix, so raising it here rather than doing it.Found while reading the config for #16.