TotalFinder attempts to re-report crash from yesterday

TotalFinder
1

Issue:
TotalFinder just attempted to re-report crash that I experienced and reported yesterday.

Details:
TotalFinder crashed yesterday, I opted to report, it created the gist upload, and I sent in the email.

Today, after several hours on my machine, TF suddenly says it crashed (it did not, I was not even interacting with it) – I opt to report, it uploads a new gist of the same crash report, and opens a new email form.

Evidence:
Original gist: https://gist.github.com/anonymous/1225900939b1d67d0ecf
New, identical gist: https://gist.github.com/anonymous/488ce1af1f96a498cb1c

Are there any logs I can dig up to help you with this issue?

I’m not really bothered by it, but if it happens a lot, you’ll probably get a confusing mess of reports. Hope this helps, thanks for making awesome software!

2

Thanks for reporting. This is definitely something I should investigate.

The reporter wakes up on any file activity in UserDiagnosticsReports folder and investigates reports that are no more than 10 seconds old:

And this is a function I took from some other project:

The problem will be in that 10 seconds interval computation, or bug in that filtering function or in your system not having file timestamps in a consistent state.

3

Found it!
Apple’s crash report collection tool, SubmitDiagInfo, modified the file which triggered your watcher:

https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man8/SubmitDiagInfo.8.html

As a result, the crash file now has:
last modified of: Mar 14 11:36:21 2014
created time of: Mar 13 17:38:23 2014

My system logs showing the culprit:

Mar 14 11:36:20 glyakbook.gly.local SubmitDiagInfo[50799]: SubmitDiagInfo successfully uploaded 115 diagnostic messages.
Mar 14 11:36:20 glyakbook.gly.local SubmitDiagInfo[50798]: Submitted crash report: file:///Users/ethan/Library/Logs/DiagnosticReports/Sublime%20Text%202_2014-03-13-121014_GLYakBook-2.crash
Mar 14 11:36:21 glyakbook.gly.local SubmitDiagInfo[50798]: Submitted crash report: file:///Users/ethan/Library/Logs/DiagnosticReports/SourceTree_2014-03-13-122540_GLYakBook-2.crash
Mar 14 11:36:21 glyakbook.gly.local SubmitDiagInfo[50798]: Submitted crash report: file:///Users/ethan/Library/Logs/DiagnosticReports/python_2014-03-13-173359_GLYakBook-2.crash
Mar 14 11:36:21 glyakbook.gly.local SubmitDiagInfo[50798]: Submitted crash report: file:///Users/ethan/Library/Logs/DiagnosticReports/python_2014-03-13-173400_GLYakBook-2.crash
Mar 14 11:36:21 glyakbook.gly.local SubmitDiagInfo[50798]: Submitted crash report: file:///Users/ethan/Library/Logs/DiagnosticReports/python_2014-03-13-173402_GLYakBook-2.crash
Mar 14 11:36:21 glyakbook.gly.local SubmitDiagInfo[50798]: Submitted crash report: file:///Users/ethan/Library/Logs/DiagnosticReports/python_2014-03-13-173404_GLYakBook-2.crash
Mar 14 11:36:21 glyakbook.gly.local SubmitDiagInfo[50798]: Submitted crash report: file:///Users/ethan/Library/Logs/DiagnosticReports/python_2014-03-13-173616-1_GLYakBook-2.crash
Mar 14 11:36:21 glyakbook.gly.local SubmitDiagInfo[50798]: Submitted crash report: file:///Users/ethan/Library/Logs/DiagnosticReports/python_2014-03-13-173616_GLYakBook-2.crash
Mar 14 11:36:21 glyakbook.gly.local SubmitDiagInfo[50798]: Submitted crash report: file:///Users/ethan/Library/Logs/DiagnosticReports/Finder_2014-03-13-173823_GLYakBook-2.crash
Mar 14 11:36:22 glyakbook.gly.local TotalFinderCrashWatcher[26327]: '/Users/ethan/Library/Logs/DiagnosticReports/Finder_2014-03-13-173823_GLYakBook-2.crash' crash report was related to the target app -> open Crash Reporting Dialog
Mar 14 11:36:29 glyakbook.gly.local TotalFinderCrashWatcher[26327]: Uploading crash report to gist.github.com: /Users/ethan/Library/Logs/DiagnosticReports/Finder_2014-03-13-173823_GLYakBook-2.crash
Mar 14 11:36:30 glyakbook.gly.local TotalFinderCrashWatcher[26327]:   => https://gist.github.com/488ce1af1f96a498cb1c

(Edit: formatted log output)

4

Great job, detective!

It means I should not trust filesystem timestamps and analyse timestamps in filenames instead. This kinda sucks, but I will do that.

5

This is a fix going into 1.5.23:

It is a lazy solution, but should work reliably without testing.