Skip to contentSkip to conversation

Documenting stat(2)

DISCUSSION Eric S. Raymond 3 participants 3 messages Jan 18, 2001

lore
Share & tools
lore
#0 lore raw

I'm trying to pin down and document the behavior of the size field in stat(2) on Linux and under various stat emulations on Windows and the Mac. What I find out will be documented where it will do some good (in particular I'll send a stat.2 man page patch to Andries Brouwer).

Here is what I think I know about stat(2) that isn't in the Linux man pages:

* For a plain file or directory (S_IFREG or S_IFDIR), the st_size field reports the size of the file in bytes.

* For a symlink (S_IFLNK) it reports the size of the link file, not the size of the file the link points to.

* For a socket or FIFO (S_IFSOCK, S_IFIFO) it reports the count of bytes waiting to be read.

* For a block special device (S_IFBLK) it returns 0.

I don't know what it should be expected to return for terminal or other special devices. My guess is number of characters waiting in clists.

Can anyone verify, correct, or expand on the above? Reply to [email protected], please, and thanks in advance.

(Among other things, this may turn into a substantial improvement in the documented capabilities of Perl and Python.)

Signature · 12 lines
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The spirit of resistance to government is so valuable on certain
occasions, that I wish it always to be kept alive.  It will often be
exercised when wrong, but better so than not to be exercised at all.
I like a little rebellion now and then.  It is like a storm in the
Atmosphere.
	-- Thomas Jefferson, letter to Abigail Adams, 1787
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#1 lore raw

In article <[email protected]>,

Quoted 3 lines · Eric S. Raymond

* For a socket or FIFO (S_IFSOCK, S_IFIFO) it reports the count of bytes waiting to be read.

Don't depend on it. That's pretty much implementation-defined: use the FIONREAD ioctl to fetch available info from pipes, sockets, ttys etc.

Some versions of Linux will _not_ give the size of the pipe from stat(), if I remember correctly. And as far as I know, no version of Linux will have st_size mean anything at all for sockets (pipes, yes. Both named and unnamed - at least with the current implementation. But not sockets. How could, it, anyway, as a socket name is nothing but a bind entry, and can have many sockets associated with it?).

Quoted 1 line

* For a block special device (S_IFBLK) it returns 0.

Again, this is not something you should depend on. Older Linuxes tried to return the size of the block device, again if my memory serves me.

Quoted 3 lines

I don't know what it should be expected to return for terminal or other special devices. My guess is number of characters waiting in clists.

Nope. Use FIONREAD for that.

Linux will normally return 0.

Quoted 2 lines

Can anyone verify, correct, or expand on the above? Reply to [email protected], please, and thanks in advance.

Basically, the _only_ think you should depend on is that st_size contains:
- for regular files, the size of the file in bytes
- for symlinks, the length of the symlink.

That's it. Anybody who tries to use anything else is nonportable, and is almost guaranteed to not work reliably even on just different versions of Linux, never mind anything else.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#2 lore raw
In reply to Eric S. Raymond

Thus spake Eric S. Raymond ([email protected]):

Quoted 5 lines

Here is what I think I know about stat(2) that isn't in the Linux man pages:

* For a symlink (S_IFLNK) it reports the size of the link file, not the size of the file the link points to.

I think you confuse stat and lstat here.

Felix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/