* filer.remote.sync: do not pin the sync offset on completed work
* filer.remote.sync: a superseded rename uploads the current entry; typed NotFound for a stamp on a deleted entry
* filer.remote.sync: a superseded rename keeps the old key when it is the only copy and uploads once
* filer.remote.sync: a rename whose content is now remote-only fails the event instead of completing it
* filer.remote.sync: a remote-only rename copies the old object to the destination before deleting it
* filer.remote.sync: the remote-only rename path follows the filer's current entry and verifies the destination object
* filer.remote.sync: an event that described an entry without data is superseded once the filer wrote to it
* filer.remote.sync: a superseded rename does only the work left to do
uploadCurrentEntry met a remote-only current entry with a fixed error, but a
sync plus remote.uncache in the meantime leaves the destination holding the
stamped object; that state is complete, not lost. The remote-only case now
finishes through completeRemoteOnlyRename, which verifies the destination
against the entry stamp and fails only when neither key holds the content.
A current entry whose stamp covers its content was already uploaded by the
superseding event; skip it instead of writing the same bytes again.
* filer.remote.sync: an inherited stamp does not prove the content synced
The stamp-coverage skip in uploadCurrentEntry read LastLocalSyncTsNs as
proof the current content was uploaded, but a rename carries the source
entry's stamp to the destination: a rewrite hidden by that stamp (the case
the fallback upload exists for) carries a LastLocalSyncTsNs at or after its
mtime and would have been skipped. Drop the check; the remote-only path
verifies content at the destination itself through describes.
---------
Co-authored-by: James Sas <james@medable.com>
Co-authored-by: Chris Lu <chris.lu@gmail.com>
