Talk:stat (system call)

Wikipedia limits

I found this page on "Unix Stat" while doing a search for unix programming topics (3/4/07) I feel strongly that the resources of Wikipedia should not be wasted on recreating or mirroring another "d_mned" unix manual on the web. There are ample resources for programming and operating systems related concerns on the web and so while the "history of" would be alright for Wiki. It is wholly inappropriate as a mirror or summary of so much material already available on the web (last look +1 million hits and counting)... Wiki editors you need to put limits which prevent wiki from becoming a "web to itself". Like a good poem...Wiki will benefit from the constraints of common sense. 71.156.174.2 21:23, 4 March 2007 (UTC)

So how about the other religions? After all, the whole unix manual is quite short MX44 (talk) 22:26, 4 February 2009 (UTC)

The UNIX manuals are by no means complete, much less encyclopedia entries. Just because they exist isn't an excuse not to provide *real* background on Wikipedia. Speaking of background, stat is quite important on UNIX, and deserves a bit more. A few examples might make a good start. —Preceding unsigned comment added by 69.143.218.125 (talk) 14:25, 1 July 2010 (UTC)

Your contributions would be appreciated. Wikipedia is only as good as it's contributors. This page could use some serious work. Cheers, — sligocki (talk) 18:08, 3 July 2010 (UTC)

Corrections

"Writing to a file changes its mtime, ctime, and atime."

This isn't correct (at least in either UNIX or Linux), as the atime does not get updated on writes. Article corrected. Slay2k (talk) 02:22, 5 March 2009 (UTC)

"A change in file permissions or file ownership changes its ctime and atime."

Also appears incorrect. The atime is not updated on inode changes. Slay2k (talk) 02:41, 5 March 2009 (UTC)

Criticism of atime

It doesn't seem like so much of this article should be devoted to critisism of atime, this article is about the system call stat(), not some design decisions of POSIX systems. Cheers, — sligocki (talk) 21:20, 29 April 2010 (UTC)

Agreed, and a lot of the information should be in the article about inodes instead.Furrfu (talk) 09:20, 10 May 2013 (UTC)

Removed. TwoTwoHello (talk) 22:58, 27 September 2014 (UTC)

Hello! I'd say that we should leave it as part of the article, at least until it's dissolved into other articles. With that in mind, I've restored the deleted content. Let's make a plan where to move what, if you insist on deleting it. — Dsimic (talk | contribs) 09:48, 30 September 2014 (UTC)

Hi! I don't think it can stay in this article as it is not about the system call, the sourcing is poor and it smacks of wp:Coatracking. I can't think of another article where this level of detail would be appropriate. The only other article I have found where it might be relevant is POSIX, which I notice has a controversies section. If a decent source could be found, I guess a summary of the atime controversy could be added there. In the meantime, I propose moving it to this talk page. TwoTwoHello (talk) 10:58, 8 October 2014 (UTC)

I agree with your concern that the article might be seen as a WP:COATRACK, as the lengths of different sections make it look like that. On the other hand, the whole thing about the negative performance impacts of constant atime updates is quite important, and it's a real and very widespread issue. At the same time, atime values are fetched through the stat() system call, which this article is all about. Regarding the references, I'd say that's already covered as "Once upon atime" and "That massive filesystem thread", for example, are just fine.

With all that in mind, how about compacting the stat (system call) § Criticism of atime section (and possibly renaming it to "atime performance issues", for example), instead of deleting it or moving somewhere else? I'm more than willing to do that, if you agree, and we could then move on from there. Thoughts? — Dsimic (talk | contribs) 17:05, 8 October 2014 (UTC)

I've had a flick through Advanced Programming in the UNIX Environment, first edition, and it has 17 references to stat in the index but no references to atime. Chapter 4 "Files and Directories" describes the stat system call and goes through each member of the stat structure in turn filling 30 pages before it discusses atime, mtime and ctime which it covers in 4 pages. It does not criticise atime and it is clear that atime is only a small part of its coverage of the system call stat. If reliable secondary sources that cover the system call do not criticise atime then nor should this article: the section gives it WP:UNDUE weight. Neither of the above references mention the stat system call.

I think the performance implications of atime are interesting and would like to read a discussion of it in an article on filesystem performance, if we had one. The fact that atime values are fetched through the stat system call is much too small a hook to hang such a discussion here; the stat system call has nothing to do with the performance overhead of maintaining access times.

I suggest renaming the section "atime" and reducing it to a discussion of the semantics of the various atime options in fstab. The rest of the section should be moved to this talk page so that it is preserved for use elsewhere. TwoTwoHello (talk) 10:56, 9 October 2014 (UTC)

Hm, please let's remember that Advanced Programming in the UNIX Environment pretty much dates back from the "Slowaris" times of sync-mounted filesystems, so it's slightly apart from modern developments. Please let me think about the whole thing once again, and I'll come back with an update as soon as possible. — Dsimic (talk | contribs) 15:12, 9 October 2014 (UTC)

Unfortunately, I still haven't found a more appropriate place where this content could be moved; of course, I'm not going to stop thinking about it. However, I'm still against plain deletion of the content (moving it to a talk page isn't much different), so I'd guess that we should hear opinions from other editors as well. — Dsimic (talk | contribs) 06:01, 20 October 2014 (UTC)

rdev?

rdev redirects to this article. What is it? --Abdull (talk) 09:34, 2 December 2010 (UTC)

When the redirect from rdev to stat (Unix) was created in 2004 the article mentioned the entries of the thirteen-element array returned by the stat() function in Perl.[1] rdev is one of the elements of this array. — Tobias Bergemann (talk) 07:51, 3 December 2010 (UTC)

Merge suggestion

Why isn't this just merged with http://en.wikipedia.org/wiki/Sys/stat.h —Preceding unsigned comment added by 94.101.1.72 (talk) 01:57, 28 April 2011 (UTC)

Recently sys/stat.h was turned into a redirect. I changed it to point here and intend to merge anything worth merging. Vadmium (talk, contribs) 02:41, 7 October 2012 (UTC).

creation time on ext4 filesystems?

The ext4 file-system supports the storing of the real creation time. How can it be read out? This is also not explained in the article. --37.209.89.166 (talk) 15:35, 1 September 2014 (UTC)

time_t vs struct timespec

Hello, @Schily. It was just a typo, the correct names are st_mtim, st_atim and st_ctim and these are of type struct timespec not time_t. st_mtim(e), st_atim(e) and st_ctim(e) are legacy definitions, of type time_t. But since 2008, struct timespec is preferred over time_t, since it provides a higher resolution time. -- Bkouhi (talk) 16:40, 3 March 2015 (UTC)

But people would be very confused with st_mtime == timespec, as newer UNIX implementations (e.g. since Solaris 2.1 from December 1992, when struct timespec was introduced for struct stat) of course still have #define st_mtime mtim.tv_sec. Schily (talk) 17:45, 3 March 2015 (UTC)

semantics of fstat are poorly explained.

Notably, fstat offers a nofollow attribute and thus the behavior must be configured by the user. — Preceding unsigned comment added by 2001:16B8:1435:7F00:A86D:AA00:19C:1468 (talk) 08:29, 6 May 2022 (UTC)