 |
 |
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 >>>>>> >>>> >>>> >> >>