Hi Andy,
I agree. Let's say it in this way: I do not have anything against it.
If somebody has, please comment now on it.
Fabrizio
Andrew Hanushevsky wrote:
> Hi Fabrizio,
>
> Depends on your viewpoint. As the documentation was relatively fuzzy in
> this regard, one could claim that it is still within the bounds of
> resonable accomodation. Others would claim that the semantics have
> changed. The point is, of course, does it really matter at this point.
>
> Andy
>
>
> On Thu, 30 Aug 2007, Fabrizio Furano wrote:
>
>> 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
>>>>>>
>>>>
>>>>
>>
>>
|