AccessPathName() fails for remote files (xrootd?)

The AccessPathName() method seems to not work correctly for remote files (I believe this is xrootd protocol used here):

gSystem->AccessPathName(“root://castoratlast3//castor/cern.ch/user/m/mschott/testarea/Zmumu/Zmumu_3_AOD.023533._00085.pool.root.2”,kFileExists)
(Bool_t)1
(1 or true means the file does not exist)

but TFile::Open() will open the same file without problems.
I see it with root 5.18 and 5.22.

Is that a bug? If yes, are there any workarounds?

Hi,

No, that’s not a bug, just the fact that the URL in that form tries to access the file via rootd or xrootd on host castoratlas3. And that setup does not exists.

For castor files you should use the castor protocol: this works also for me

root [0] gSystem->AccessPathName("castor:/castor/cern.ch/user/m/mschott/testarea/Zmumu/Zmumu_3_AOD.023533._00085.pool.root.2",kFileExists)
(Bool_t)0

To actually open the file you need to set by hand the env variable RFIO_USE_CASTOR_V2 to YES:

export  RFIO_USE_CASTOR_V2=YES

and then

f = TFile::Open("castor:/castor/cern.ch/user/m/mschott/testarea/Zmumu/Zmumu_3_AOD.023533._00085.pool.root.2")

G. Ganis

Hello,

I do not quite understand what you mean by “the setup does not exist”.
As I wrote, the file can be opened without any problems:
root [1] f=TFile::Open(“root://castoratlast3//castor/cern.ch/user/m/mschott/testarea/Zmumu/Zmumu_3_AOD.023533._00085.pool.root.2”);
Warning in TClass::TClass: no dictionary for class…

root [3] f->Print()
TFile: name=root://castoratlast3//castor/cern.ch/user/m/mschott/testarea/Zmumu/Zmumu_3_AOD.023533._00085.pool.root.2, title=AOD.023533._00085.pool.root.2, option=READ

But still gSystem->AccessPathName() will claim this file does not exist. That does not look consistent, and the application refuses to work (because it is using AccessPathName() as a test if the file is there).
Using Castor path is not an option - the actual problem was reported from HPSS setup in Lyon which is based on xrootd - the test file at CERN is just an example.

Ok, sorry, I misunderstood your first report.

Could you please set some verbosity with

root [0] gEnv->SetValue("XNet.Debug", 2)

and run again AccessPathName and Open, and send me what you get on the screen ?
Please do the two cases in different sessions, so that I can see what happens at connection.

G. Ganis

I am attaching the debug output from the 2 commands. I think there is an interesting error reported on the first case:

090130 11:20:14 001 Xrd: SendGenCommand: Sending command Stat 090130 11:20:14 001 Xrd: CheckErrorStatus: Server declared: Unable to set the stager host - you didn't specify it and I have no stager map for fn = /castor/cern.ch/user/m/mschott/testarea/Zmumu/Zmumu_3_AOD.023533._00085.pool.root.2; Invalid argument(error code: 3005)
log.txt (20.4 KB)

Hello Marcin, ganis,

What’s the current status of this bug? Can it be easily patched?
The reason I ask, is b/c for Atlas purposes it would be great if we could
still have this patched this week, before the build of root v5.22a :wink:

Cheers,
-Max

Hello,

Comparing the outputs for AccessPathName and Open, one sees that the difference is that the Open request is redirected to the relevant data-server, while the ‘stat’ (AccessPathName) is not.

This indicates that the problem is on the server side.
I had a confirmation about this hypothesis from Andreas Peters, the main developer of the server-side plug-in used in this case.
He is investigating.

As far as I can see now, there is nothing to be patched in 5.22.
I guess that Andreas will deploy the fix/solution as soon as available.

G. Ganis

Yes indeed it looks like a server side problem.
Thank you for following this up Gerardo. Please let us know if there are any new developments.

The instance you use is a Castor2.1.8 instance with new xrootd interface. The convenience that users are automatically mapped to a default stager and service class has only be added for file opens. If you use stat commands, the deployed instance requires that you add to the URLs the opaque tags: "root:///?stagerHost=&svcClass=

In this case the AccessPathname() function should work properly.

I will port the ‘open’ mapping to the the ‘stat’ function and will rebuild new RPMs. I cannot give a time estimate when this fix can be deployed. Since it is not linked with the Castor release process it might be actually very soon.

In any case you could verify that it works as expected using the addional & correct opaque tags for the ATLAS stager in the URLs.

Cheers, Andreas Peter - IT-DM-DA

The fix for the mentioned problem has been release with the Castor 2.1.8-6 xroot release.
Now it is ‘only’ a matter of deployment.

Sorry to re-open this very old thread, but I am having a similar problem and, from the previous discussion, I could not understand what is the solution to it.

I am using gSystem->AccessPathName(fileName.Data()) to verify if a file on a disk server exists.
The disk server is based on DPM and I usually access files with paths like

root://atlasse.lnf.infn.it//dpm/lnf.infn.it/home/vo.padme.org/daq/2020/rawdata/run_0030279_20200731_140609/run_0030279_20200731_140609_lvl1_00_000.root

Access via gfal-ls or TFile works fine but gSystem->AccessPathName reports an error:

InputHandler::OpenFileInStream - Filename root://atlasse.lnf.infn.it//dpm/lnf.infn.it/home/vo.padme.org/daq/2020/rawdata/run_0030279_20200731_140609/run_0030279_20200731_140609_lvl1_00_000.root
Error in TFile::TFile: file /dpm/lnf.infn.it/home/vo.padme.org/daq/2020/rawdata/run_0030279_20200731_140609/run_0030279_20200731_140609_lvl1_00_000.root does not exist

Is gSystem->AccessPathName supposed to work with my configuration? What is the right way to do it?

Thank you

Emanuele Leonardi