«

I'm playing with FUSE's python bindings, and I'm expected to return a
list that matches the structure of a python os.lstat() call. So, for
example:

>>> import os
>>> os.lstat("/home/adrian/fuse_test")
(16877, 10666636L, 2050L, 4, 1000, 1000, 4096L, 1184803155,
1184170289, 1184170289)

The problem is, I'm not sure how to recreate this kind of structure
because I have no idea about the significance of the entries. The
docstring wasn't much help:

>>> print os.lstat.__doc__
lstat(path) -> stat result

Like stat(path), but do not follow symbolic links.
>>> print os.stat.__doc__
stat(path) -> stat result

Perform a stat system call on the given path.

I checked the online Python documentation at http://python.org/doc/1.5.2/lib/module-stat.html
but it just says to "consult the documentation for your system.". At
this point I'm guessing that os.lstat is nothing more than a wrapper
for some Linux system call, so I looked up the results of running
'stat' on the same file, and I get:

adrian@adrian-desktop:~$ stat fuse_test/
File: `fuse_test/'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 802h/2050d Inode: 10666636 Links: 4
Access: (0755/drwxr-xr-x) Uid: ( 1000/ adrian) Gid: ( 1000/
adrian)
Access: 2007-07-18 19:59:15.000000000 -0400
Modify: 2007-07-11 12:11:29.000000000 -0400
Change: 2007-07-11 12:11:29.000000000 -0400

I can see some correspondence between the "stat" call and os.lstat
(for example, I'm guessing os.lstat(path)[6] represents the filesize),
but I can't see the correspondence between some of the other fields.
What does os.lstat(path)[0] represent? Are those last three the
created/modified/accessed times in unix time or what? Basically, what
does each field of os.lstat(path) represent?

My system is Linux 2.6.20 and I'm using Python 2.5.1
Thanks in advance, guys! =)

On Wed, Jul 18, 2007 at 05:55:59PM -0700, Adrian Petrescu wrote:
> I can see some correspondence between the "stat" call and os.lstat
> (for example, I'm guessing os.lstat(path)[6] represents the filesize),
> but I can't see the correspondence between some of the other fields.
> What does os.lstat(path)[0] represent? Are those last three the
> created/modified/accessed times in unix time or what? Basically, what
> does each field of os.lstat(path) represent?

There's a whole module available explicitly for "interpreting
results of os.stat() and os.lstat()."

http://www.python.org/doc/current/lib/module-stat.html

--

[Will Maier]-----------------[|http://www.lfod.us/]

Adrian Petrescu <> writes:

> I checked the online Python documentation at http://python.org/doc/1.5.2/lib/module-stat.html
> but it just says to "consult the documentation for your system.".

The page you're looking for is at
http://www.python.org/doc/current/lib/os-file-dir.html . For lstat it
says "Like stat(), but do not follow symbolic links." For stat it
says:

Perform a stat() system call on the given path. The return value
is an object whose attributes correspond to the members of the
stat structure, namely: st_mode (protection bits), st_ino (inode
number), st_dev (device), st_nlink (number of hard links), st_uid
(user ID of owner), st_gid (group ID of owner), st_size (size of
file, in bytes), st_atime (time of most recent access), st_mtime
(time of most recent content modification), st_ctime (platform
dependent; time of most recent metadata change on Unix, or the
time of creation on Windows)
[...]
For backward compatibility, the return value of stat() is also
accessible as a tuple of at least 10 integers giving the most
important (and portable) members of the stat structure, in the
order st_mode, st_ino, st_dev, st_nlink, st_uid, st_gid, st_size,
st_atime, st_mtime, st_ctime. More items may be added at the end
by some implementations. The standard module stat defines
functions and constants that are useful for extracting information
from a stat structure. (On Windows, some items are filled with
dummy values.)

Adrian Petrescu <> wrote:
>>>> print os.stat.__doc__
>stat(path) -> stat result
>
>Perform a stat system call on the given path.
>
>I checked the online Python documentation at http://python.org/doc/1.5.2/lib/module-stat.html

Someone else has already pointed out that this is hopelessly out of
date. Even if you are constrained to using 1.5.2, the current
documentation at least tells you what the elements of the tuple are.

>but it just says to "consult the documentation for your system.". At
>this point I'm guessing that os.lstat is nothing more than a wrapper
>for some Linux system call, so I looked up the results of running
>'stat' on the same file, [ ... ]

(a) Running 'stat' is *not the same* as a system call.

(b) "Consult[ing] the documentation" may be more productive than
running random(ish) programs. You should find

$ man 2 stat

informative.

--
\S -- -- http://www.chaos.org.uk/~sion/
"Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

On Jul 19, 4:27 am, Hrvoje Niksic <hnik...@xemacs.org> wrote:
> Adrian Petrescu <apetr...@uwaterloo.ca> writes:
> > I checked the online Python documentation athttp://python.org/doc/1.5.2/lib/module-stat.html
> > but it just says to "consult the documentation for your system.".
>
> The page you're looking for is athttp://www.python.org/doc/current/lib/os-file-dir.html. For lstat it
> says "Like stat(), but do not follow symbolic links." For stat it
> says:
>
> Perform a stat() system call on the given path. The return value
> is an object whose attributes correspond to the members of the
> stat structure, namely: st_mode (protection bits), st_ino (inode
> number), st_dev (device), st_nlink (number of hard links), st_uid
> (user ID of owner), st_gid (group ID of owner), st_size (size of
> file, in bytes), st_atime (time of most recent access), st_mtime
> (time of most recent content modification), st_ctime (platform
> dependent; time of most recent metadata change on Unix, or the
> time of creation on Windows)
> [...]
> For backward compatibility, the return value of stat() is also
> accessible as a tuple of at least 10 integers giving the most
> important (and portable) members of the stat structure, in the
> order st_mode, st_ino, st_dev, st_nlink, st_uid, st_gid, st_size,
> st_atime, st_mtime, st_ctime. More items may be added at the end
> by some implementations. The standard module stat defines
> functions and constants that are useful for extracting information
> from a stat structure. (On Windows, some items are filled with
> dummy values.)

Thank you, both Will and Hrvoje. Those links answer my questions.

> (a) Running 'stat' is *not the same* as a system call.

Why do you say that? It is *exactly* the same, at least
on a POSIX system (on Windows, there is no stat, so the
implementation has to map that to several system calls).

Regards,
Martin

=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?= <> wrote:
>> (a) Running 'stat' is *not the same* as a system call.
>Why do you say that? It is *exactly* the same [ ... ]

Maybe if stat were implemented as

int main(int argc, char** argv) {
struct stat so_what_am_I_supposed_to_do_with_this;
return stat(argv[1], &so_what_am_I_supposed_to_do_with_this);
}

But it obviously does a lot of other stuff, including formatting
the results of the system call for display. Since what it really
at issue here is presentation of the results, I'd say that the
stat system call and the stat program wrapping it are very
different things.

--
\S -- -- http://www.chaos.org.uk/~sion/
"Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

> But it obviously does a lot of other stuff, including formatting
> the results of the system call for display.

It most decisively does *not* format the results of the system call
"for display". Instead, it converts the C data type holding the
stat result into a Python data type. That data type historically
was a tuple, but now is struct-like type with the same fields as
the C data type.

It's the same as saying "+ does not do addition. It does a lot
of other stuff, including the formatting of the result of the
operation for display".

> Since what it really
> at issue here is presentation of the results, I'd say that the
> stat system call and the stat program wrapping it are very
> different things.

This is probably a matter of opinion. I think it is important
to understand that Python does *not* do any significant code
to os.stat and os.lstat; entirely unlike libraries in other
languages that attempt to also change the programming API in
the process of wrapping the system API.

Regards,
Martin

=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?= <> wrote:
>> But it obviously does a lot of other stuff, including formatting
>> the results of the system call for display.
>It most decisively does *not* format the results of the system call
>"for display".

"It" here refers to the program stat, which on most systems I use
is in /usr/bin/stat and most assuredly *does* format the results of
the system call for display.

> I think it is important
>to understand that Python does *not* do any significant code
>to os.stat and os.lstat;

Absolutely, which is why I consider it foolish for the OP to be
trying to deduce the meaning of os.stat by looking at the output
of the stat program, rather than studying the man page for the
stat system call.

--
\S -- -- http://www.chaos.org.uk/~sion/
"Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

> Absolutely, which is why I consider it foolish for the OP to be
> trying to deduce the meaning of os.stat by looking at the output
> of the stat program, rather than studying the man page for the
> stat system call.

Ah, ok. I missed that the OP had brought stat(1) into the
discussion. Now it's all clear.

Martin