mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-18 21:16:47 +00:00
bcdb931a34
A run stored the cursor of the listing it started from, whatever it did afterwards. Paperless, Papra and Synology build that cursor from what they list, so a copy TREK uploaded and somebody deleted at the provider before the next run left the scope exactly as the stored listing had it. The next plain run (scheduler, webhook, Sync now) read the cursor as unchanged, planned only the TREK side, and neither flagged the copy as missing nor asked the mass-delete guard until something else moved in the scope or a full run came along. A copy TREK binned and somebody restored at the provider read the same way. WebDAV was not affected: its root ETag never returns to an earlier value. The same held for a run that stopped short. What the transfer budget left over, and a download that failed, was never planned again under an unchanged cursor, so on a quiet binding those documents did not arrive at all. A run now keeps the listing's cursor only when it ended ok and asked the provider to change nothing: no upload, no rename, no trash. Any other run stores none, and the next one compares both sides in full and hands a cursor on once it ends clean. On Paperless, Papra and Synology that costs nothing, since they walk the scope on every run anyway; on WebDAV it is one Depth:1 listing instead of the Depth:0 probe.