Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: st_mtime, st_size, and time consuming writes.
57 views
Skip to first unread message
Message has been deleted
Nicolas George
Nov 26, 2012, 11:35:26 AM11/26/12
to
"In a Very Dark Blue, China Blue Condition" , dans le message
<chine.bleu-4C343...@news.eternal-september.org>, a écrit :
> Is st_mtime potentially updated with every write, when st_size is? Or is
> it only updated on major operations like open or close or etc?
>
> I need to monitor if a file is being modified in any other process.
> Currently I check if st_mtime or st_size change, but I was wonderring if
> it is enough to check st_mtime.
Why don't you just try?
I would be surprised if the Unix standard specified the behaviour exactly.
<chine.bleu-4C343...@news.eternal-september.org>, a écrit :
> Is st_mtime potentially updated with every write, when st_size is? Or is
> it only updated on major operations like open or close or etc?
>
> I need to monitor if a file is being modified in any other process.
> Currently I check if st_mtime or st_size change, but I was wonderring if
> it is enough to check st_mtime.
Why don't you just try?
I would be surprised if the Unix standard specified the behaviour exactly.
Nobody
Nov 26, 2012, 12:09:04 PM11/26/12
to
On Mon, 26 Nov 2012 07:49:29 -0800, In a Very Dark Blue, China Blue
Condition wrote:
> Is st_mtime potentially updated with every write, when st_size is? Or is
> it only updated on major operations like open or close or etc?
It is supposed to update st_mtime with every write(), but there may be
Condition wrote:
> Is st_mtime potentially updated with every write, when st_size is? Or is
> it only updated on major operations like open or close or etc?
filesystems (e.g. networked filesystems, particularly those designed for
other OSes) where this doesn't happen.
> I need to monitor if a file is being modified in any other process.
> Currently I check if st_mtime or st_size change, but I was wonderring if
> it is enough to check st_mtime.
fields is negligible.
While any write() should update both st_size and st_mtime (if the
filesystem doesn't always report changes immediately, it will probably
update either both neither), st_mtime isn't guaranteed to have better than
one second resolution, so it isn't guaranteed that st_mtime will actually
change for each write(). OTOH, when a write() overwrites existing
data rather than extending the file, st_size won't change.
Nicolas George
Nov 26, 2012, 12:53:04 PM11/26/12
to
Nobody , dans le message <pan.2012.11.26....@nowhere.com>, a
écrit :
kernel's inode cache, that is very cheap, it is just a matter of storing an
int32 or int64 in a structure when that structure is already being updated
(st_size and marking it dirty). It will take a little time to actually reach
the physical device, but that does not matter, because stat()s from another
process will read from the very same inode cache.
écrit :
> It is supposed to update st_mtime with every write()
A side note on that: the st_mtime is updated in the inode inside the
kernel's inode cache, that is very cheap, it is just a matter of storing an
int32 or int64 in a structure when that structure is already being updated
(st_size and marking it dirty). It will take a little time to actually reach
the physical device, but that does not matter, because stat()s from another
process will read from the very same inode cache.
Geoff Clare
Nov 27, 2012, 8:40:57 AM11/27/12
to
Nicolas George
Nov 27, 2012, 9:16:02 AM11/27/12
to
Geoff Clare , dans le message
<9gseo9-...@leafnode-msgid.gclare.org.uk>, a écrit :
> It does.
[citation needed]
<9gseo9-...@leafnode-msgid.gclare.org.uk>, a écrit :
> It does.
[citation needed]
Philip Guenther
Nov 27, 2012, 6:08:59 PM11/27/12
to
On Tuesday, November 27, 2012 6:16:02 AM UTC-8, Nicolas George wrote:
> Geoff Clare , dans le message
> <9gseo9-...@leafnode-msgid.gclare.org.uk>, a �crit�:
> Geoff Clare , dans le message
>
> > It does.
>
> [citation needed]
http://lmgtfy.com/?q=unix+specification+st_mtime+write
Message has been deleted
Nicolas George
Nov 28, 2012, 3:47:13 AM11/28/12
to
"In a Very Dark Blue, China Blue Condition" , dans le message
<chine.bleu-617CF...@news.eternal-september.org>, a écrit :
> Knowing there was an answer let me find
> http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html
Ok. For some reason, the next version of the standard has changed the
wording to remove mention of st_mtime and replace it with "the last data
modification and last file status change timestamps". That defeats grepping.
Geoff Clare
Nov 28, 2012, 8:39:44 AM11/28/12
to
replaced with st_mtim which has type struct timespec, thus allowing
finegrained timestamps. For backwards compatibility <sys/stat.h>
defines an st_mtime macro which expands to st_mtim.tv_sec.
Likewise for st_atim[e] and st_ctim[e].
--
Geoff Clare <net...@gclare.org.uk>
Nicolas George
Nov 28, 2012, 8:43:10 AM11/28/12
to
Geoff Clare , dans le message
<0qgho9-...@leafnode-msgid.gclare.org.uk>, a écrit :
> There is no longer an st_mtime field in struct stat. It has been
> replaced with st_mtim which has type struct timespec, thus allowing
> finegrained timestamps. For backwards compatibility <sys/stat.h>
> defines an st_mtime macro which expands to st_mtim.tv_sec.
Oh, I had not realized that. That is very good news. Thanks for pointing it
> replaced with st_mtim which has type struct timespec, thus allowing
> finegrained timestamps. For backwards compatibility <sys/stat.h>
> defines an st_mtime macro which expands to st_mtim.tv_sec.
out.
Noob
Dec 22, 2012, 4:21:38 AM12/22/12
to
China Blue wrote:
> Knowing there was an answer let me find
> http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html
For the sake of completeness, Issue 6 (IEEE Std 1003.1-2004) has
> Knowing there was an answer let me find
> http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html
been superseded by Issue 7 (IEEE Std 1003.1-2008).
http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html
Regards.
0 new messages