Repository navigation
Fix recursive downloads of unmounted shared folders - #401
Merged
AndreyVMarkelov merged 1 commit intoNov 12, 2026
Conversation
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.
Recursive shared-link downloads fail with
invalid shared link entry path ""when Dropbox omits path metadata for a folder that is not mounted in the caller's account. Build each entry's relative path from the folder being listed and itsName, rather than parsingPathDisplayand stripping the root name.Reject empty names, dot segments, absolute paths, and names containing path separators before downloading files or queuing folders. Regression coverage includes listings with and without path metadata, nested downloads, pagination, existing targets, and unsafe names.
Validation:
go test ./...go vet ./...go build ./...share-link download --recursivefails for every entry when the shared folder isn't in the caller's Dropbox #393 with the old binary against an external folder whose entry omittedpath_display; the fixed binary downloaded successfully to new, existing, and default targets. File size and Dropboxcontent_hashmatched in each case. JSON output,--pathto stdout, and rejection without--recursivealso passed.get, plus a synthetic fixture with three directory levels, Unicode, spaces, an empty directory, and a child matching the root name. The synthetic link was revoked and the remote fixture removed.Fixes #393.
Related: #396 (closed without merging).