On Sat, Sep 25, 2021 at 06:02:50PM +0000, Al Viro wrote: > On Sat, Sep 25, 2021 at 10:15:07AM -0700, Rustam Kovhaev wrote: > > Hello Alexander and linux-fsdevel@, > > > > I would like to propose saving a new note with timestamp in core file. > > I do not know whether this is a good idea or not, and I would appreciate > > your feedback. > > > > Sometimes (unfortunately) I have to review windows user-space cores in > > windbg, and there is one feature I would like to have in gdb. > > In windbg there is a .time command that prints timestamp when core was > > taken. > > > > This might sound like a fixed problem, kernel's core_pattern can have > > %t, and there are user-space daemons that write timestamp in the > > report/journal file (apport/systemd-coredump), and sometimes it is > > possible to correctly guess timestamp from btime/mtime file attribute, > > and all of the above does indeed solve the problem most of the time. > > > > But quite often, especially while researching hangs and not crashes, > > when dump is written by gdb/gcore, I get only core.PID file and some > > application log for research and there is no way to figure out when > > exactly the core was taken. > > > > I have posted a RFC patch to gdb-patches too [1] and I am copying > > gdb-patches@ and binutils@ on this RFC. > > Thank you! > > IDGI. What's wrong with the usual way of finding the creation date of any > given file, including the coredump one? Sometimes file attributes get reset/modified when the file changes hands. Here is what usually happens: We ask customer to take a few cores of some hanging process, customer does so, then copies the files out from his Linux servers/machines, then creates an archive on his machine (usually windows/mac) and then, emails or uploads the archive, and, if we are lucky we get correct creation date of the core in the archive, but most of the time creation date gets reset/modified somewhere along this process.
