dCache server does not return the pin lifetime

With GFAL API it is possible to pass to the SRM server a pin lifetime when making a BringOnline request. But here there is a bug: with dCache SURL the pin lifetime is not returned by the SRM. Result of the prestage_status is:

results:  {
'status': 0, 
'surl': 'srm://gridka-dCache.fzk.de/pnfs/gridka.de/lhcb/disk-only/lhcb/production/DC06/phys-v2-lumi5/00001877/DST/0000/00001877_00000196_5.dst', 
'turl': None,
 'explanation': '[SE][StatusOfBringOnlineRequest] AsyncWait'}

Whereas with CASTOR the result is

results:  {
'status': 1,
 'surl': 'srm://srm-lhcb.cern.ch/castor/cern.ch/grid/lhcb/production/DC06/phys-v2-lumi5/00001877/DST/0000/00001877_00000196_5.dst', 
'turl': None,
 'explanation': '[SE][StatusOfBringOnlineRequest] SRM_FILE_PINNED', 
'pinlifetime': 600}

the 'pinlifetime' key is not present in the result dictionary returned by the GFAL API for dCache surl.

I traced the process of prestaging for the dCache surl. The pin lifetime is correctly sent from the client to SRM server. But later, in the srmBringOnlineResponse the pin lifetime is not returned. The field 'remainingPinTime' has no value assigned.

Tracing the same process with a CASTOR surl: client sends the request to server specifying 600, then the server answers and in the srmBringOnlineResponse block the remaining pin time is correctly returned: 600. (even if then this is not respected in CASTOR).

Why doesn't dCache server return the remaining pin time?

This is a known issue: bug # 4154 in dCache RT

-- ElisaLanciotti - 25 May 2009