Marc Lehmann wrote:
Absolutely. But the ctime likely changes on file creation, or the size, or something else (such as the inode number).This all depend son how your logfiles get rotated - the file might get trucnated, deleted or somethign else might happen.
So I should be looking at the size of the file, rather than the ctime of the file?
My question is, is libev using the stat64 structure by way of comparison?No. And it wouldn't help your case unless you require the logifle to be on a specific filesystem supporting higher resolution timestamps. And even then, the higher resolution might sitll just be centiseconds or so. All this doesn't help you. The documentation (that you somehow fail to know, for inexplicable reasons) explains this case in mroe details and offers ways to implement this properly in your app.
Maybe I am looking at different documentation to you. I am looking at the following URL: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#code_ev_stat_code_did_the_file_attriThe headings I see are "ABI Issues (Largefile Support)", "Inotify and Kqueue", "stat () is a synchronous operation" and "The special problem of stat time resolution". The word "rotate" doesn't appear at all in the docs I am reading.
Is there some other docs that I should be reading but am not aware of?
Is there a cross platform method to determine file rotation, by looking at the attr and prev variables returned by a stat event?Yes, but for some reason you claim it wouldn't work.
So far I was led to believe that ctime can be used to detect file rotation, but the manpage for stat, and the code that I have in testing contradict this.
Should I be using the file length instead? Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
