sam_metadata_dumper fails to open xrootd input
The sam_metadata_dumper fails to open files passed in as xrootd uri's.
The following output demonstrates this:
[anorman@novagpvm01 xrootd]$ sam_metadata_dumper root://fndca1.fnal.gov:1094//pnfs/fnal.gov/usr/nova/scratch/users/anorman/fardet_r00011760_s59_t02_S14-01-20_v1_data.daq.root
Error in <TFile::TFile>: file /pnfs/fnal.gov/usr/nova/scratch/users/anorman/fardet_r00011760_s59_t02_S14-01-20_v1_data.daq.root does not exist
Unable to open file 'root://fndca1.fnal.gov:1094//pnfs/fnal.gov/usr/nova/scratch/users/anorman/fardet_r00011760_s59_t02_S14-01-20_v1_data.daq.root' for reading.
Skipping to next file.
As per discussion with Chris, Marc et al, this is probably just related to a check that is being done of the commandline args.
Can we have this patched to support the xrootd input. (other art based utils work as expected)
#1 Updated by Christopher Green over 6 years ago
- Category set to I/O
- Status changed from New to Feedback
- Assignee set to Christopher Green
- Priority changed from Normal to High
- Target version set to 1.09.00
- Estimated time set to 2.00 h
- Experiment NOvA added
- Experiment deleted (
- SSI Package art added
- SSI Package deleted (
I cannot identify such a check, unfortunately: something else appears to be going on. Is there some way to test this from a non-NOvA machine?
#4 Updated by Christopher Green over 6 years ago
- Status changed from Feedback to Assigned
- % Done changed from 0 to 60
This is now understood: the XROOTD-reading plugin is only activated if the static
TFile::Open() method is used.
sam_metadata_dumper was using the normal
TFile constructor. Converting
sam_metadata_dumper to use the magic method is sufficient to fix the problem.
This issue is not yet marked resolved pending the resolution of a linking problem in the new version of ROOT in the next release that was exposed by this issue.