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