Marc Lehmann wrote:
I have an fd open to the file, which will never increase in size because the file has been deleted, but my app doesn't yet know that.Is there a way to detect this?An ev_stat watcher should reliably detect that case, as logfile rotation is not very often done, so the ctime should reliably change.
I tried this out on MacOSX 10.5, and found that monitoring ctime for file rotation changes were giving me lots of false positives (the file wasn't rotated at all, but every few seconds I was detecting "changes").
Turns out according to the man pages for the stat structure, ctime is described as follows:
struct timespec st_ctimespec; /* time of last file status change */
The clarification of ctime further down is as follows:st_ctime Time when file status was last changed (inode data modi- fication). Changed by the chmod(2), chown(2), link(2), mknod(2), rename(2), unlink(2), utimes(2) and write(2)
system calls.
The fact that ctime is updated on write() means that in theory, it
cannot be used to detect file rotation.
There is also a stat64 structure, with higher precision on the file times, as follows:
struct timespec st_ctimespec; /* time of last status change */
struct timespec st_birthtimespec; /* time of file
creation(birth) */
This second stat64 definition would imply that "last status change" and "file creation" (what I am looking for) are two separate things.
My question is, is libev using the stat64 structure by way of comparison?Is there a way for me to detect whether the stat or the stat64 structure is in use at a given time?
Is there a cross platform method to determine file rotation, by looking at the attr and prev variables returned by a stat event?
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
