bf60df82401b1c11eb4cc0d9f67e76a0f0749849
max
  Fri Sep 4 12:02:30 2026 -0700
hubCheck: stop resolving bigDataUrl a second time, refs #38256

trackHubTracksForGenome() already runs expandBigDataUrl() over every stanza, which
rewrites bigDataUrl and bigDataIndex in the settings hash so they are no longer
relative to the trackDb file. hubCheckBigDataUrl() then resolved them again against
genome->trackDbFile, which prepended the hub's directory a second time. For a local
hub reached by a relative path that turned a file which is present into a file which
is reported missing:

hubCheck out/hub.txt
Couldn't open out/out/hg19/x.bb

Remote hubs and local hubs given by an absolute path were unaffected, because the
second resolution is a no-op once the path is a URL or already absolute, which is why
this went unnoticed. The tests/makefile has been working around it: the
fieldCountMismatch case has to cd into input/ before it can find its bigBed.

Added a tests/ case that does not cd, with the data file in a subdirectory below
hub.txt, the shape 'hubtools import session' now writes. Its bigBed is deliberately
declared 'type bigBed 9' when it holds 6 fields, because hubCheck can only report
that mismatch if it really opened the file. Before this change the test reported
"Couldn't open input/relPath/input/relPath/data/test6field.bb".

Verified against a binary built from the unmodified tree: this changes the output of
no other test in hubCheck/tests. Seven of those tests were already failing before
this commit and still are.

diff --git src/hg/utils/hubCheck/tests/input/relPath/hub.txt src/hg/utils/hubCheck/tests/input/relPath/hub.txt
new file mode 100644
index 00000000000..fc10ea16d81
--- /dev/null
+++ src/hg/utils/hubCheck/tests/input/relPath/hub.txt
@@ -0,0 +1,20 @@
+hub relPath
+shortLabel relPath
+longLabel bigDataUrl resolution when hub.txt is reached by a relative path
+email braney@soe.ucsc.edu
+descriptionUrl hubDescription.html
+useOneFile on
+
+genome mm10
+
+# 'type bigBed 9' deliberately disagrees with the 6 fields in the file. hubCheck can
+# only report that mismatch if it actually found and opened the file, so the mismatch
+# is what proves data/test6field.bb was resolved correctly. Declaring the true field
+# count would make hubCheck silent, and it is equally silent when it cannot find the
+# file at all, because such a track is pruned before the file check runs.
+track relPathTrack
+type bigBed 9
+bigDataUrl data/test6field.bb
+shortLabel relPathTrack
+longLabel bigDataUrl in a subdirectory below hub.txt
+visibility dense