Hi everyone, 

Another weird question.

We're using the XrdCmsTfc plugin to sanitise paths in our system - effectively normalising them by stripping out all of the leading slashes. [This is especially important for http, as get requests inherently add a leading '/', which must be removed.]

Our xrootd config seems to load the storage.xml appropriately

with 

pss.trace all 

set  we get

Plugin loaded unversioned XrdOucgetName2Name from namelib /opt/xrootd/lib64/libXrdCmsTfc-5.so
Copr. 2009 University of Nebraska-Lincoln TFC plugin v 1.0
Params: file:/etc/xrootd/storage.xml?protocol=xrootd,http,https,davs,chain
Xerces-c has been initialized.
Connecting to the catalog file:/etc/xrootd/storage.xml?protocol=xrootd,http,https,davs,chain
Using catalog file /etc/xrootd/storage.xml
------ Proxy storage system initialization completed.

logged, which seems like the "right thing" is happening. From reading the cmstfc source code, I don't expect anything else to be parsed if there's no errors.

The storage.xml looks like:

<storage-mapping>
<!-- The following is always applied (we specify protocol=xrootd in the xrootd config file) -->
<lfn-to-pfn protocol="xrootd" chain="direct" path-match="(.*)" result="$1"/>
<lfn-to-pfn protocol="http" chain="direct" path-match="(.*)" result="$1"/>
<lfn-to-pfn protocol="https" chain="direct" path-match="(.*)" result="$1"/>
<lfn-to-pfn protocol="davs" chain="direct" path-match="(.*)" result="$1"/>
<!-- Below we define the mappings used for each VO as necessary, exiting on the first match -->
<!-- Counter the problem with XRootD clients preceding an OID with an extraneous slash (especially an issue for TPC transfers) -->
<lfn-to-pfn protocol="direct" path-match="/*(.*)" result="$1"/>
</storage-mapping>

which also seems like it should do the right thing - incoming paths with leading / should be stripped out, replaced with the remaining string.

[an almost identical config does work at RAL]

In our case, though, the plugin seems to not affect path parsing at all - 

/dteam:/somefile

and

//dteam:/somefile

and

dteam:/somefile

remain distinct [and only the latter works].

Does anyone have any ideas about how I can work out what's breaking where?

I've tried different combinations of protocols specified in the string, and loading the namelib into pss.namelib or oss.namelib or both [and on both the proxy and the server behind it], but no change seems to make any difference.

Sam