fix: resolve cue FILE refs by basename against cue dir#2403
Merged
Conversation
PS1/PS2 SKU extraction returned null when a .cue FILE entry pointed to an absolute or foreign path (e.g. C:\WINDOWS\DESKTOP\CASTLEVANIA.BIN). path.resolve kept the bogus path and the sibling .bin was never scanned. Strip the FILE value to its basename (normalizing \ to /) and resolve it against the cue's own directory. When the resolved path is missing on a case-sensitive filesystem, scan the directory and match the basename case-insensitively, returning the real on-disk name. Also warn explicitly in extractPs12Sku when the resolved sniff target does not exist, instead of failing silently in the generic catch.
Contributor
So the exported parseCueReferencedFiles never hands a non-existent path to callers; unresolvable refs are filtered out instead.
Contributor
Author
|
@greptile review |
Move the file open/scan loop into scanTargetForSku so extractPs12Sku stays under the cognitive-complexity threshold, and switch the cue ref backslash normalization to String#replaceAll.
Hachi-R
approved these changes
Jul 2, 2026
Hachi-R
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, thanks for fixing this.
I reviewed the change and didn't find any blocker. The fix is nicely scoped, handles the bad absolute CUE refs case, and the case-insensitive fallback should help on Linux too.
|
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.



When submitting this pull request, I confirm the following (please check the boxes):
Fill in the PR content:
PS1/PS2 disc SKU extraction during LaunchBox ROM import returned
nullwhenever a.cuesheet'sFILEentry pointed somewhere other than a sibling filename. Some discs were mastered with a stale absolute path, e.g.:parseCueReferencedFilesfed that value straight intopath.resolve, which discards the cue's own directory for an absolute/\-separated path and hands back the bogus location.fs.openthen throwsENOENT, the generic catch swallows it, and the real sibling.binis never scanned.What this does
FILEvalue to its basename (normalizing\to/first) and resolves it against the cue's own directory.CASTLEVANIA.BIN, file isCastlevania.bin), it scans the directory and matches the basename case-insensitively, returning the actual on-disk name.logger.warninextractPs12Skuwhen the resolved sniff target does not exist, so future cases are diagnosable instead of failing silently.Testing
Verified end-to-end against a real affected ROM (
Castlevania.cue+Castlevania.bin): the cue's badC:\WINDOWS\DESKTOP\CASTLEVANIA.BINnow resolves to the siblingCastlevania.bin, and the scan yields the correct SKUSLUS-00067.tsctypecheck passes.