The file has timed out now and so I cannot test this, but I did not
try any of the srm commands. I am still learning as I go and did not
know about this command set. I will give it a go next time we hit this
Just to ask, can I do this as just and lcgadmin of a VO or would
someone with root access to the SE itself have to do this?
On 1 Jul 2010, at 13:13, Sam Skipsey wrote:
> 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.
> 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
>> 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
>> such a file.
>> On 30 Jun 2010, at 16:45, Sam Skipsey wrote:
>>> 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
>>> / 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
>>> If a file is in absolutely urgent need of deletion, to the extent
>>> you don't mind overcoming SRM's own protections in files, I think
>>> only totally effective way is for someone local to remove it from
>>> underlying filesystem or SE.
>>> But, again, I'd need more context to understand why you'd want to
>>> do that.
>>> On 30 June 2010 16:13, Ben Still <[log in to unmask]> wrote:
>>>> After a chat with Chris Walker here at QMUL we have drawn a blank
>>>> as to
>>>> 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
>>>> 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?
>>>> Dr Ben Still
>>>> Postdoctoral Research Assistant
>>>> Particle Physics Research Centre
>>>> Queen Mary, University of London
>>>> G.O. Jones Building
>>>> 327 Mile End Road
>>>> 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
>> 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
E1 4NS, UK
[log in to unmask]