Skip to content

context: resolve files whose names contain glob metacharacters (e.g. IMG_0347[1].jpg)#309

Merged
JamesHabben merged 1 commit into
abrignoni:mainfrom
OneSixForensics:fix/resolve-glob-metachar-filenames
Jun 27, 2026
Merged

context: resolve files whose names contain glob metacharacters (e.g. IMG_0347[1].jpg)#309
JamesHabben merged 1 commit into
abrignoni:mainfrom
OneSixForensics:fix/resolve-glob-metachar-filenames

Conversation

@OneSixForensics

Copy link
Copy Markdown
Contributor

Summary

Context.get_source_file_path() silently fails to resolve any file whose name contains a glob metacharacter — [, ], *, or ?. These are common in real device data (e.g. IMG_0347[1].jpg, [clips4sale.com]clip.mp4), so affected files are dropped from artifacts and never linked/rendered.

Root cause

When multiple candidates share a basename, the resolver disambiguates with Path(candidate).match(partial_path). Path.match treats the argument as a glob pattern, so metacharacters in a real filename are interpreted as wildcards and the match fails — the file resolves to nothing.

for candidate in candidate_paths:
    if Path(candidate).match(partial_path):   # partial_path used as a glob
        return candidate
return None

Fix

  • Single-candidate shortcut: when the basename maps to exactly one path, return it directly — no pattern match needed (the common case).
  • Exact-suffix fallback: keep the existing Path.match for back-compat, then fall back to a literal normalized path-suffix comparison, which resolves any filename regardless of metacharacters.

Behavior is unchanged for all currently-working filenames; it only adds resolution for names that previously failed.

Context

Split out of #284 as its own PR per @JamesHabben's suggestion, so the framework patch can be evaluated/merged independently of the Synchronoss module. The identical fix is already merged in iLEAPP (#1620), ALEAPP (#916), and VLEAPP (#74). Closes #286. Validated against a real ~32 GB return (17,214 device-backup files, many with bracketed names — all now resolve).

Context.get_source_file_path() verifies a candidate with
Path(candidate).match(partial_path). Path.match is glob-based, so real
filenames containing glob metacharacters ('[', ']', '*', '?') never match —
e.g. "IMG_0347[1].jpg" or "[clips4sale.com]video.wmv", which are pervasive in
real cloud/device-backup returns. check_in_media then logs "No matching file
found" and registers no media for those files.

The filename map is already keyed on the exact basename, so:
- a single candidate is unambiguous and is returned directly (also the fast
  path), and
- when several files share a basename, fall back to an exact path-suffix
  comparison after the existing Path.match attempt.

Closes abrignoni#286.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BdD6DdQA21KqDRSUjQHaTK
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

check_in_media silently drops files whose names contain glob metacharacters ([ ] * ?)

2 participants