[ntpl] Allow XRootD redirection with EOS files

[vepadulano]

Fixes #20213

With these changes I can see the redirection happening when reading an RNTuple on EOS from lxplus (going from ntpl001_staff.root to root://eoshome-v.cern.ch//eos/user/v/vpadulan/ntpl001_staff.root

Breakpoint 1, ROOT::Internal::RRawFile::Create (url=..., options=...) at /tmp/vpadulan/root/io/io/src/RRawFile.cxx:88       
88         std::string transport = GetTransport(url);                                                                       
(gdb) n  
89         if (transport == "file") {
(gdb) p url                                                                                                                 
$1 = {_M_len = 18, _M_str = 0x4030a3 "ntpl001_staff.root"}  
[...]
103                    if (auto baseName = fileNameFromUrl.substr(fileNameFromUrl.find_last_of("/") + 1);
(gdb) 
105                       return Create(xurl, options);
(gdb) s
[...]
Breakpoint 1, ROOT::Internal::RRawFile::Create (url=..., options=...) at /tmp/vpadulan/root/io/io/src/RRawFile.cxx:88       
88         std::string transport = GetTransport(url);                                                                       
(gdb) n                                                                                                                     
89         if (transport == "file") {                                                                                       
(gdb) 
113        if (transport == "http" || transport == "https" ||
(gdb) p url
$8 = {_M_len = 64, _M_str = 0x136a790 "root://eoshome-v.cern.ch//eos/user/v/vpadulan/ntpl001_staff.root"}
(gdb) p transport
$9 = {static npos = 18446744073709551615, 
  _M_dataplus = {<std::allocator<char>> = {<std::__new_allocator<char>> = {<No data fields>}, <No data fields>}, 
    _M_p = 0x7fffffffa230 "root"}, _M_string_length = 4, {
    _M_local_buf = "root\000\177\000\000\220\242\377\377\377\177\000", _M_allocated_capacity = 139639930187634}}
(gdb) 

There might be more places where the redirection needs to happen though.

[jblomer]

Thanks for addressing this!

[github-actions]

Test Results

    21 files      21 suites   3d 3h 28m 48s ⏱️
 3 857 tests  3 815 ✅  0 💤  42 ❌
73 345 runs  73 175 ✅ 32 💤 138 ❌

For more details on these failures, see this check.

Results for commit d447fee.

♻️ This comment has been updated with latest results.

[vepadulano]

To the best of my understanding, this PR is simply moving the code that used to live separately in TFile::Open and RLoopManager::ChangeSpec extracting it into a common place. I have been testing these changes on EOS. Both TFile::Open and RNTupleReader::Open work flawlessly. For some reason, with the redirection happening in RDataFrame to store also the redirected URL as a sample ID, I see this error

terminate called after throwing an instance of 'std::runtime_error'
  what():  Full sample identifier 'root://eoshome-v.cern.ch//eos/user/v/vpadulan/rdf_sample.root/events' cannot be found in the available samples.

which is the same that triggered #17544 . What's even more worrying is that I don't see the error on every test execution, but sometimes the test also runs without failing. Before merging this PR I need to understand why that happens. It's possible the problem is still there somehow also without the code changes of this PR.

[jblomer]

In principle looks good to me! We should think about how to test it. Extended attributes are file system dependent, so we may need to add some code just for testing, e.g. something that lets us control what GetXAttrVal returns under unit tests.

[vepadulano]

Regarding the issues with the eos.url.xroot attribute being wrong:

• Wrong URL returned for eos.url.xroot attribute cern-eos/eos#41 describes the issue I remembered about the base name sometimes not being populated. I remember this still happening last year, can't say for sure at this point, but at some point it was there.
• URL for eos.url.xrot attribute wrongfully injects double forward slash in directory name cern-eos/eos#50 describes a new regression that introduces double forward slash in the XRootD URL, thus breaking all versions of ROOT relying on this redirection

I would wait for the latter issue to also be confirmed fix before moving on with this PR, FYI @amadio.

[jblomer]

@vepadulano it looks like this PR can advance