I agree with you that both of those, the *LIB and the database *FILE,
are native OS/400 object types. I think what you are missing, is the
probability that the code was written something like the following [not
to imply that I know; I do not]:
dcl is_dir int init 0
dcl is_lnk int init 0
dcl is_ntv int init 0
dcl is_sck int init 0
when object_is_container() then is_dir = 1;
when object_is_socket() then is_sck = 1;
when object_is_lnk() then is_lnk = 1;
... if ... is_ntv = 1; ...
Implication being that probably, once the code determines that the
object is capable of drill-down, being an effective /directory/, the
IsNative likely just remains unset, due to how it was coded. However I
doubt even if anyone in development agreed, they'd probably just say
/working as designed/ even though more likely it is /working as coded/;
or at least state that it is too dangerous to change because someone
[the OS itself, being most notable] may have coded to that anomalous
outcome, irrespective of how illogical. No harm in trying :-)
Simon Coulter wrote:
Has anyone else noticed that st_mode returned by stat() and its
siblings evaluates to false for S_ISNATIVE when a *LIB or *FILE
object is the target?
Both *LIB and *FILE objects evaluate to true for S_ISDIR which
makes sense given they are containers for other objects and thus,
at least conceptually, directory objects.
However, I would have thought that they are both also native
objects. That is "things what are" in QSYS.LIB rather than in
other file systems.
Seems to me that S_ISNATIVE should evaluate to true for any
QSYS.LIB object. Given that each type evaluated by the various
S_ISxxxx macros is actually a separate bit in the mode it seems
reasonable that the native bit could be set in addition to the
directory bit thus allowing both S_ISDIR and S_ISNATIVE to
evaluate to true for *LIB and *FILE objects.
Of course, objects not in QSYS.LIB would not have the native bit
set (even though they are MI objects).
What am I missing?