Bug #113100 for File-Tail: Request change to resetafter behavior

Explain in more detail what you mean "turn off the resetafter behaviour", please. Do you mean, not open a new file when the old has been rotated at all? Or something else? I consider the transparent way of handling the file being rotated/replaced a major point of functionality for File::Tail. Unfortunately a side effect is that sometimes I get a false positive (think that a file has been rotated when it really has not been) and the same file is opened again. If you find a reliable way to generate a false positive, let me know, and I'll try to find a way to avoid it. On 03/16/2016 11:50 PM, Nathan Goodman via RT wrote: Show quoted text

Show quoted text
I mean do not reopen the file even if it's been quiet for a long time. In my application, there's no possibility of the file being rotated - the program that generates the log doesn't rotate it. So for my application, if the file is quiet it just means the program that's generating the log hasn't had anything to say for a while. I can do this (on Unix-like systems anyway) with 'tail -f -n +1', but I like the OO line-oriented interface you provide. I appreciate the importance of handling file-rotation in some applications, perhaps most. Telling whether a file has been rotated seems hard because of all the ways this might be done. On a Unix-like system, if the original file is renamed and a new one created, I think it would work to check the inode number: the original file will keep the original inode number and the new file will have a new inode number. Seems easy enough. But if the original file is deleted and a new one created, it's possible that the inode number will be reused for the new file. A similar, logically equivalent, situation occurs if the original file is truncated. Perhaps for these cases you can use the modification time and file size to figure it out: you can consider it "new" if the file has shrunk or if it's the same size but the mod time is different. The hard case is if it's bigger, since it's not obvious whether the old file grew or there's new file that happens to be bigger. For this final case, perhaps you can use a checksum to figure it out: compute an incremental checksum as you process the file, then recompute it upon re-reading the file and see it's the same up to the end position you last saw on the old file. This seems like a lot of work, but if this behavior is important, you probably need to do something like this. The current behavior only does the right thing if (a) the file really has been rotated, and (b) nothing was written to the old file since the last time you looked at it. An alternative is to rewrite the whole thing on top of 'tail' which has functionality to follow rotated files. I have no idea how well it works, but it might be worth taking a look. It's probably fair to say that whatever 'tail' does is good enough, since I imagine that's what most people use. Thanks again for the great module and your attention to this problem. Best, Nat On Thu Mar 17 10:56:47 2016, matija@serverflow.com wrote: Show quoted text