Replies: 1 comment 1 reply
-
That omission is deliberate to avoid people ascribing meaning to event time. At one end of the scale there's simple undetectable order inversion and at the other there's that on some platforms it's perfectly acceptable for the OS to send events dozens of minutes out of date, or worse. Also see the note in the manual about rename events. (More generally, you can't use filesystem events of this level to faithfully represent what took place at all. The only three correct ways to do that are to lower your resolution dramatically and do full scans on change ("here's the diff between time X and Y"), or to read the low level filesystem journal ("here's exactly all the operations that got done on this entire partition per inode and file extent"), or to intercept calls via trace ("here's every write() syscall this program did") or custom FUSE drivers ("here's a log of all the writes for this mountpoint"). Everything else is approximation.) |
Beta Was this translation helpful? Give feedback.
-
I think it would be nice to have a flag to enable recording the wall clock time each event was received and report it in events. I think the timing (especially when potentially buffered streams are involved) and maybe even order of received events might not be the most faithful possible representation of what took place.
Beta Was this translation helpful? Give feedback.
All reactions