xrdfs listing doesn't process correctly the URL parameters

[costing]

Hi,

For a command like
xrdfs <server> ls -l /00/00016?<parameters>
the client appends the returned file names to the output, producing blocks of text like
drwx 2016-01-30 09:11:22 512 /00/00016?<parameters>/ffd8a058-6367-11e4-a9c9-eb62cad7fc4a

This is not only an output problem, but also it seems that it does stat on the same path, instead of appending the parameters at the end of it, eg
/00/00016/ffd8a058-6367-11e4-a9c9-eb62cad7fc4a?<parameters>

The effect is that the stat is done on the directory itself and all files are marked as 'd' and with the virtual size of the directory entry.

Cheers,

.costin

[simonmichal]

Hi Costin,
I could easily reproduce the first problem, meaning opaque info included in the path (this can be easily fix).

But, I was not able to see the 'directory' effect, e.g.:

xrdfs slc7-test ls -l /tmp/data?DummyParam
-rw- 2016-02-22 14:23:06 0 /tmp/data?DummyParam/file1
-rw- 2016-02-22 14:23:07 0 /tmp/data?DummyParam/file2
-rw- 2016-01-21 15:16:54 1832850589 /tmp/data?DummyParam/ESD.05723687._000004.pool.root.1
-rw- 2016-03-04 14:21:39 0 /tmp/data?DummyParam/new_file

Files are not listed as directories and their size is correct. Could you give some more details on what params are you using?

Thanks,
Michal

[costing]

Hi Michal,

Thanks a lot for looking into this issue!

The 'directory' effect was in the mean time tracked to dCache not implementing kXR_dstat (see #332) with the effect that the client was falling back to an older implementation (listing without stat) and the client was composing the path itself and filling the stat with probably some default values (if I understood it correctly). But this is not an issue any more since the new method was quickly implemented by the dCache developers.

That leaves just the opaque information part.

Cheers,

.costin

[simonmichal]

Thanks a lot for clarifying! :)