posixmodule.c and configure have several provisions to
make st_rdev, st_blocks, and st_blksize accessible if
the host system supports them.
Unfortunately, the length of the returned stat tuple
does not reflect this. The fix is trivial -- replace
a literal "10" with 1 + the highest index macro.
That fix makes all detectable fields accessible, but
it may be that configure only discovers support for
some of the fields in which case it is impossible to
decide which of the last couple elements refer to which
fields. E.g if configure only finds st_rdev there is
no way for a running program to easily know that.
In any event we surely want ST_RDEV fields, etc. as for
the rest of the stat fields (for consistency, if
nothing else). The simplest fix is to have the posix
module itself define the ST_RDEV and friends slot name
variables. Then the stat module can simply try to take
them from the "os" module.
I'm submitting a patch which does all these things.
In particular I have a very nice categorical,
colorizing "ls" written purely in 500 lines of Python,
but it cannot do long listings for device files since
the st_rdev just isn't there. Also "du" in Python
would fail in the presence of sparse files since
st_blocks is missing. These fields have been around
forever. It's about time we actually get the support
working.
Long term it would probably be best if the "os/posix"
module defined the variables that the stat module
currently does. This would simplify any portability
issues since the C code can just use the configure
macros. For backward compatibility a stat module could
remain that just imported all the correct names from
the os module.
|