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