Interpreting os.lstat()

[Adrian Petrescu]

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:
(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:
lstat(path) -> stat result

Like stat(path), but do not follow symbolic links.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! =)

 

[Will Maier]

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

 

[Hrvoje Niksic]

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

 

[Sion Arrowsmith]

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.

 

[Adrian Petrescu]

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.

 

[=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=]

(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

 

[Sion Arrowsmith]

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

 

[=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=]

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

 

[Sion Arrowsmith]

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.

 

[=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=]

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