You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that FileRotate panics if the rotated files are deleted or moved away from the log folder while the application logging through FileRotate is still running.
More precisely, the crash is caused by this assert, in which the code is checking that the file to be renamed in a rotation still exists.
I think the reason for that assert is that FileRotate makes a snapshot of the currently rotated files in the log folder when the scan_suffixes method is called in the constructor, and then assumes that the rotated files will not be moved/deleted by an external process.
Do you think it might be possible to lighen this assumption and be more robust to this usecase?
Thanks for your input on this 🙂
The text was updated successfully, but these errors were encountered:
Yeah, that should be made more robust. I guess instead of the assert, we should just call scan_suffixes again if those assumptions are not true (and recurse? or a while loop or something).
I'll get to this next week probably, unless there be a PR before that time ;)
Current blocker is concern about race conditions in the comments of my PR.
I wonder if we should use lock files or something, or if we can solve it in another way.
I noticed that
FileRotate
panics if the rotated files are deleted or moved away from the log folder while the application logging throughFileRotate
is still running.More precisely, the crash is caused by this assert, in which the code is checking that the file to be renamed in a rotation still exists.
I think the reason for that assert is that
FileRotate
makes a snapshot of the currently rotated files in the log folder when thescan_suffixes
method is called in the constructor, and then assumes that the rotated files will not be moved/deleted by an external process.Do you think it might be possible to lighen this assumption and be more robust to this usecase?
Thanks for your input on this 🙂
The text was updated successfully, but these errors were encountered: