mirror of
https://github.com/narrrl/proton-drive-linux.git
synced 2026-11-03 16:41:26 +01:00
nvrl
e32959e40a
The SDK caches each node, including the name hash it sends with the next rename or move, and only an event evicts it. Renames and moves didn't update that copy. So after a rename, the next change to the same node went out with the old name hash, Drive refused it as out of date (422), and the retry kept sending the stale hash until the event feed came round, up to 10 seconds later. - Every remote rename and move goes through `Core::rename_remote` or `Core::move_remote`. Both drop the SDK's copy of the node after a successful change and before each out-of-date retry, so the retry sends the current hash. - A plain move was not retried at all, so a move right after a rename failed with EIO through the mount and with "out of date" from `pdfs move`. It now retries like a rename. - The drain's combined move-and-rename also drops the SDK's copy once it lands. - A rename that also changes folders through the mount replies only once both halves have landed. When the move fails, the file keeps its new name in the source folder, the tree is told so, and the rename reports EIO. A dropped link still queues the change. B111's cause in docs/BUGS.md is corrected to the same SDK cache. The acceptance case "regression B121" renames and moves a file at once through the mount and through `pdfs`, and checks names and bytes.