Repository navigation
Conversation
hasSyncThingFile only listed the top level of the download folder. Season packs that keep each episode in its own folder could therefore start extracting while Syncthing was still copying volumes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
With
syncthing = true,hasSyncThingFileonly lists the top level of the download folder. Season packs that keep each episode in its own folder don't put temp files there, so extraction can start while Syncthing is still copying volumes.We hit this with a 5-episode RAR pack, where each episode folder held about 85 × 50 MB volumes. Sonarr reported the download as complete while Syncthing was still copying it. Unpackerr started 2 minutes later, having found only one of the five archives, with no "still syncing" line in the log, and failed with:
The RAR header reports the full 4.3 GB, but only the volumes copied so far count towards the compressed size. Because it's a limit error, the item is set to
NoRetryand stays failed until someone retries it by hand.I reproduced the error with xtractr v0.8.0 and
MaxRatio: 7.5: the first few volumes of the set fail with this error, and the complete set passes the check.Fix
hasSyncThingFilenow usesfilepath.WalkDir, so temp files in subfolders hold the extraction back as well. Walk errors are ignored, since Syncthing renames and removes temp files during the walk. The.tmpmatch is unchanged.Testing
TestHasSyncThingFileFindsTempFileInSubfolder, which fails without this change.go test ./pkg/...passes.Question for you (not in this PR)
Should a ratio failure stay
NoRetrywhen the RAR volume set is incomplete? This PR closes the Syncthing path, but a set that's incomplete for any other reason would still get stuck, even though a later retry would succeed. I left it alone because the no-retry rule looks deliberate for real zip bombs. I'm happy to send a follow-up if you'd like one.🤖 Generated with Claude Code