fix(filer.sync): derive the rename delete key like the create key, guard the watched root

The rename delete leg rebuilt the old key with a raw util.Join, bypassing the
sink-side key normalization the create leg gets from buildKey — so a rename
could create the new entry and then fail to delete the old one under a
transformed key. Build the old key through buildKey too, and skip the delete
when the moved entry is the watched root itself (where the old key would
resolve to the target root and recursively delete the whole sink tree).
This commit is contained in:
Chris Lu
2026-06-09 09:57:13 -07:00
parent 296d6c2eb0
commit 8d8c07a2eb
+7 -3
View File
@@ -619,9 +619,13 @@ func genProcessFunction(sourcePath string, targetPath string, excludePaths []str
if err := dataSink.CreateEntry(newKey, message.NewEntry, message.Signatures); err != nil {
return fmt.Errorf("create entry2 : %w", err)
}
if doDeleteFiles {
oldKey := util.Join(targetPath, string(sourceOldKey)[len(sourcePath):])
if err := dataSink.DeleteEntry(string(oldKey), message.OldEntry.IsDirectory, false, message.Signatures); err != nil {
// derive the old key the same way as the new one so the delete
// targets the same sink-side normalization the create used. Guard
// against the watched root itself moving, where the old key would
// resolve to targetPath and recursively delete the whole sink tree.
if doDeleteFiles && string(sourceOldKey) != sourcePath {
oldKey := buildKey(dataSink, message, targetPath, sourceOldKey, sourcePath)
if err := dataSink.DeleteEntry(oldKey, message.OldEntry.IsDirectory, false, message.Signatures); err != nil {
return fmt.Errorf("delete old entry %v: %w", oldKey, err)
}
}