filer.remote.sync: keep doc comments on the functions they describe

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

weed/command/filer_remote_sync_dir.go

@@ -615,8 +615,6 @@ func releaseRenamedSource(filerSource filer_pb.FilerClient, client remote_storag
 	return releasePendingSource(filerSource, client, mountedDir, remoteStorageMountLocation, message.OldEntry)
 }
 
-// currentEntry returns what the filer holds at dir/name now, nil when the
-// entry is gone.
 // remoteSyncLookupTimeout bounds a filer lookup on the sync path. A lookup
 // that never answers keeps its job alive, the job keeps its path in the
 // processor's conflict index, and the stream stops behind it.
@@ -626,6 +624,8 @@ func lookupContext() (context.Context, context.CancelFunc) {
 	return context.WithTimeout(context.Background(), remoteSyncLookupTimeout)
 }
 
+// currentEntry returns what the filer holds at dir/name now, nil when the
+// entry is gone.
 func currentEntry(filerSource filer_pb.FilerClient, dir, name string) (*filer_pb.Entry, error) {
 	ctx, cancel := lookupContext()
 	defer cancel()
@@ -1010,6 +1010,10 @@ func entryDiffers(entry, current *filer_pb.Entry) bool {
 		len(filer.DoMinusChunks(current.GetChunks(), entry.GetChunks())) > 0
 }
 
+// remoteUploadChunkCache is one per process: a chunk cache runs a worker
+// goroutine that nothing stops, so a cache per upload leaks one per file.
+var remoteUploadChunkCache = chunk_cache.NewChunkCacheInMemory(8)
+
 // remoteUploadReader streams the entry's full declared size through
 // ChunkReadAt, which zero-fills any range no chunk view covers: a sparse
 // file, a mid-write snapshot flushed while its chunk uploads were still
@@ -1018,10 +1022,6 @@ func entryDiffers(entry, current *filer_pb.Entry) bool {
 // the backend a short body on every retry — a hole that never fills wedges
 // the event, and a backend that does not verify the length publishes a
 // truncated object.
-// remoteUploadChunkCache is one per process: a chunk cache runs a worker
-// goroutine that nothing stops, so a cache per upload leaks one per file.
-var remoteUploadChunkCache = chunk_cache.NewChunkCacheInMemory(8)
-
 func remoteUploadReader(filerClient filer_pb.FilerClient, entry *filer_pb.Entry) (reader io.Reader, closeFn func() error, err error) {
 	if len(entry.Content) > 0 {
 		return bytes.NewReader(entry.Content), nil, nil

weed/command/filer_remote_sync_dir_test.go

@@ -538,22 +538,6 @@ func entryWith(name string, remote *filer_pb.RemoteEntry, chunks ...*filer_pb.Fi
 	return &filer_pb.Entry{Name: name, Attributes: &filer_pb.FuseAttributes{Mtime: 1786096669}, RemoteEntry: remote, Chunks: chunks}
 }
 
-// TestIsSuperseded decides what a failed upload means for its event (#11148).
-// A replay from an earlier offset re-emits creates for entries the filer has
-// since deleted or rewritten; their chunks are gone, so the upload can never
-// succeed, and failing the event pins the offset before it forever. Those are
-// skipped. A failure to upload an entry the filer still holds as described is
-// a real failure and must keep failing the event so the subscription retries.
-//
-// Every write stores its chunks under new file ids, so the entry is compared
-// by chunk identity, the way the filer itself decides which chunks an update
-// leaves for deletion. Content fingerprints would miss a delete-and-recreate
-// of identical bytes and fail the event forever on its dead chunks.
-//
-// Chunks the filer has added since count too. The event was then a snapshot
-// of a write in progress: a mount flushes metadata while chunk uploads are
-// still running, so the snapshot can have holes, and the stream reader stops
-// at the first one on every retry.
 // blockingFilerClient answers a lookup only when its context ends.
 type blockingFilerClient struct {
 	stubFilerClient
@@ -704,6 +688,22 @@ func TestRemoteUploadReaderSharesOneChunkCache(t *testing.T) {
 	}
 }
 
+// TestIsSuperseded decides what a failed upload means for its event (#11148).
+// A replay from an earlier offset re-emits creates for entries the filer has
+// since deleted or rewritten; their chunks are gone, so the upload can never
+// succeed, and failing the event pins the offset before it forever. Those are
+// skipped. A failure to upload an entry the filer still holds as described is
+// a real failure and must keep failing the event so the subscription retries.
+//
+// Every write stores its chunks under new file ids, so the entry is compared
+// by chunk identity, the way the filer itself decides which chunks an update
+// leaves for deletion. Content fingerprints would miss a delete-and-recreate
+// of identical bytes and fail the event forever on its dead chunks.
+//
+// Chunks the filer has added since count too. The event was then a snapshot
+// of a write in progress: a mount flushes metadata while chunk uploads are
+// still running, so the snapshot can have holes, and the stream reader stops
+// at the first one on every retry.
 func TestIsSuperseded(t *testing.T) {
 	const dir = "/buckets/ingest"
 	event := entryWith("tmpjt9req69__Alan_Doe_Resume-1.pdf", nil, chunk("3,01", "e1"), chunk("3,02", "e2"))