XROOTD-L Archives

Support use of xrootd by HEP experiments

XROOTD-L@LISTSERV.SLAC.STANFORD.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Fabrizio Furano <[log in to unmask]>
Date:
29 Aug 2007 11:21:30 +0200Wed, 29 Aug 2007 11:21:30 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (96 lines)
Hi Andy,

  yes, that means ok, even if I do not understand what's the point in 
changing that. When you commit please drop me a line, otherwise the 
client will be not aligned with the server. You also have to change the 
protocol id, to make the client aware of which response format it has to 
expect.

Fabrizio


Andrew Hanushevsky wrote:
> Hi Fabrizio,
> 
> So, does that mean your ok with the change?
> 
> Andy
> 
> ----- Original Message ----- From: "Fabrizio Furano" 
> <[log in to unmask]>
> To: "Andrew Hanushevsky" <[log in to unmask]>
> Cc: <[log in to unmask]>; <[log in to unmask]>
> Sent: Tuesday, August 28, 2007 1:26 AM
> Subject: Re: Proposed statx Protocol Change
> 
> 
>> Hi all,
>>
>>  afaik the only problem I am aware of (if it's stuill there) was that 
>> at some point the server returnde an error if one of the files did not 
>> exist. This obviously screwed up the meaning of statx.
>>
>>  From my opint of view I don't need to change the flag set with an 
>> equivalent one, since the wrapping in XrdClientAdmin takes care of 
>> those flags and is quite consolidated (except in the case the server 
>> returns errors instead of flags). But I ignore if there is some other 
>> reason.
>>
>> Fabrizio
>>
>>
>> Andrew Hanushevsky wrote:
>>
>>> As we all probably know, there have been several complaints about 
>>> statx. It's been a very problematic protocol element. In order to 
>>> simplify it and make it more consistent I'd like to change the 
>>> meaning of the flags whch would them allow an implementation that 
>>> makes sense,
>>>
>>> The currently returned flags are:
>>> flags    identifies the entry's attributes as a binary character. The 
>>> entry should be assumed to be an immediately available regular file 
>>> unless one or more of the following bits are set.
>>>
>>>        kXR_xset         - Either an executable file or a searchable 
>>> directory.
>>>
>>>        kXR_isDir      - This is a directory.
>>>
>>>        kXR_other      - This neither a file nor a directory, or does 
>>> not exist.
>>>
>>>  kkXR_offline - For files, the file is not online (i.e., on disk).
>>>
>>>        I would like to change it to be:
>>>
>>> kXR kXR_exists     - Object exists and is either an file or a directory.
>>>
>>>        kXR_offline - For files, the file is not online (i.e., on disk).
>>>
>>> Any  Hence, the object does not exist if all the bits are set to 
>>> zero. I can make the corresponding client code changes to ease the 
>>> effort. Anyone would rather not?
>>>
>>> a       Andy
>>>
>>>
>>>
>>> a
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> OI
>>
>>
>>




ATOM RSS1 RSS2