Interpreting os.lstat()

Discussion in 'Python' started by Adrian Petrescu, Jul 19, 2007.

  1. 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! =)
    Adrian Petrescu, Jul 19, 2007
    #1
    1. Advertising

  2. Adrian Petrescu

    Will Maier Guest

    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/]
    Will Maier, Jul 19, 2007
    #2
    1. Advertising

  3. 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.)
    Hrvoje Niksic, Jul 19, 2007
    #3
  4. 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
    Sion Arrowsmith, Jul 19, 2007
    #4
  5. On Jul 19, 4:27 am, Hrvoje Niksic <> wrote:
    > Adrian Petrescu <> 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. :)
    Adrian Petrescu, Jul 19, 2007
    #5
  6. > (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?=, Jul 20, 2007
    #6
  7. =?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
    Sion Arrowsmith, Jul 20, 2007
    #7
  8. > 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?=, Jul 20, 2007
    #8
  9. =?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
    Sion Arrowsmith, Jul 21, 2007
    #9
  10. > 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
    =?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=, Jul 21, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Chermside

    RE: lstat(fileName)[ST_SIZE]

    Michael Chermside, Jun 10, 2005, in forum: Python
    Replies:
    0
    Views:
    406
    Michael Chermside
    Jun 10, 2005
  2. Giampaolo Rodola'

    Is os.lstat available on all platforms?

    Giampaolo Rodola', Nov 29, 2007, in forum: Python
    Replies:
    2
    Views:
    233
    Giampaolo Rodola'
    Nov 29, 2007
  3. onLINES

    lstat() and stat()

    onLINES, Sep 30, 2008, in forum: C Programming
    Replies:
    4
    Views:
    415
    Joachim Schmitz
    Sep 30, 2008
  4. Replies:
    1
    Views:
    402
  5. alberttresens
    Replies:
    3
    Views:
    634
    Thomas Jollans
    Jul 26, 2010
Loading...

Share This Page