Hi Andy,
does this mean that the overall semantic of the request is going to
change, and not only the flags that compose the response?
Fabrizio
Andrew Hanushevsky wrote:
> Hi Gerri and Fabrizio,
>
> The problem is that the function is basically broken in the server. The
> current implementation stats each file in the list and the code gets
> confused when a redirection or error occurs. The change should allow me
> to simply report back the status of the cluster from the redirector's
> viewpoint and never redirect the client and continue down the list even
> if an error occurs. Now, from the redirector's standpoint all I know is
> whether the file is online or not. If the file is offline, it may or may
> not exist (that I can't tell). So, the statx would really be only useful
> for identifying online files. Hopefully, that functionality is enough.
>
> Andy
>
> ----- Original Message ----- From: "Gerardo Ganis" <[log in to unmask]>
> To: "Andrew Hanushevsky" <[log in to unmask]>
> Cc: "Fabrizio Furano" <[log in to unmask]>;
> <[log in to unmask]>
> Sent: Wednesday, August 29, 2007 4:46 AM
> Subject: Re: Proposed statx Protocol Change
>
>
>>
>> Hi Andy,
>>
>> If you think that the change in the flag definition will simplify
>> statx and make more reliable
>> that's fine with me.
>>
>> What made for us (at CAF) the command unusable was what seemed to be
>> an inconsistency
>> in the result (I've sent to you an example a few weeks ago).
>>
>> Is there someone using extensively statx with large number of files
>> (O(1000)) ?
>>
>> Gerri
>>
>> Fabrizio Furano wrote:
>>
>>> 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
>>>>
>>
>>
|