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?
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), 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.
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]
>
|