Sam Skipsey wrote:
> Hm.
>
> So, according to the srmv2.2 spec, an srmRm should succeed against a
> SURL, even if that SURL is currently in the state SRM_FILE_BUSY (this
> leads to whatever put operation was making the file busy failing when
> it tries to complete, but that's handled in the return code). Is this
> not working for you?
lcg-del doesn't work - at least that's what Ben tells me.
If it should, then I can file a bug against StoRM.
> Otherwise, I guess the correct thing to do is to issue an
> srmAbortFiles using the request token for the Put (if the user has
> it),
Is there an equivalent of lcg-cp to do this?
> and *then* do an srmRm to clean up the file in question.
> In any case, a failed put (that is, a transfer where there was an
> srmPreparetoPut, but no srmPutDone within the timeout) will
> automatically result in the file being removed, once the file transfer
> request has timed out.
>
I think the timeout is of the order of 4 days though...
Chris
> Sam
>
> On 30 June 2010 16:58, Ben Still <[log in to unmask]> wrote:
>> Hi Sam,
>>
>> It was a failed transfer as something went wrong on the users end, and we
>> would like to delete the open file as we are not actually transferring to it
>> - the failure means that no close signal was sent to SRM.
>>
>> There are only a handful of people (just three of us in fact) who are
>> transferring files within our t2k.org VO and I am the go to guy if something
>> goes wrong, but I am still learning too. I know which files are OK to delete
>> or not and would be stepping on no ones toes if I went ahead and deleted
>> such a file.
>>
>> Cheers,
>>
>> Ben
>>
>>
>> On 30 Jun 2010, at 16:45, Sam Skipsey wrote:
>>
>>> Hi,
>>>
>>> Can I ask for a little more context here? Files in the SRM_FILE_BUSY
>>> state are marked such because SRM thinks that they are being accessed
>>> / about to be accessed by a client. Obviously, the SRM won't let you
>>> delete a file in such a state, since someone else is apparently using
>>> it.
>>> If a file is in absolutely urgent need of deletion, to the extent that
>>> you don't mind overcoming SRM's own protections in files, I think the
>>> only totally effective way is for someone local to remove it from the
>>> underlying filesystem or SE.
>>> But, again, I'd need more context to understand why you'd want to do that.
>>>
>>> Sam
>>>
>>> On 30 June 2010 16:13, Ben Still <[log in to unmask]> wrote:
>>>> Hi,
>>>>
>>>> After a chat with Chris Walker here at QMUL we have drawn a blank as to
>>>> how
>>>> one might remove a file in the SRM_FILE_BUSY state.
>>>>
>>>> I understand that I could simply wait for the time out, but if it is
>>>> noticed
>>>> immediately and is of urgency then there seems to be no way to change the
>>>> state of the file to then delete it.
>>>>
>>>> Any ideas?
>>>>
>>>> Cheers,
>>>>
>>>> Ben
>>>>
>>>> Dr Ben Still
>>>> Postdoctoral Research Assistant
>>>> Particle Physics Research Centre
>>>> Queen Mary, University of London
>>>> G.O. Jones Building
>>>> 327 Mile End Road
>>>> London
>>>> E1 4NS, UK
>>>> [log in to unmask]
>>>>
>> Dr Ben Still
>> Postdoctoral Research Assistant
>> Particle Physics Research Centre
>> Queen Mary, University of London
>> G.O. Jones Building
>> 327 Mile End Road
>> London
>> E1 4NS, UK
>> [log in to unmask]
>>
|