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