Messages randomly fails to log conversations

I'm seeing an issue with 10.8.2 (also had it with 10.8.1) where Messages will randomly fail to log some of my conversations. "Save history when conversations are closed" is checked in Preferences, but occasionally, the log will not be saved. I only use Messages for AIM contacts, so I am not sure if this also might happen with iMessages, Yahoo, Jabber, etc.

The conversation itself happens normally, and when it's over, I close the conversation and it's removed from the left pane of the Messages window. But the next time I speak with that contact, whether by sending them a message or receiving a message from them, the immediately preceding conversation is missing from the conversation history (but the history does show older conversations that preceded the missing conversation). Looking in the Finder, there is no log file for that conversation in my logs folder. This happens only randomly and fairly rarely, from what I have noticed; it may occur once out of every 10 conversations.

This has happened with a handful of different people and it's unpredictable, so it's frustrating to lose records of conversations with no warning and with no way to get them back. The workaround is just to leave every conversation window open, but that gets very cumbersome!

I'd love to file a bug report, but I'm hoping to get some more information and perhaps figure out a pattern so I can give Apple some specifics.

Has anyone else noticed this?

Many thanks!

Okay, replying to my own post, I've managed to get a better sense as to the nature of the problem thanks to Time Machine. There seems to be a serious bug in Messages that causes data loss.

Messages/iChat logs are named in the format of "[Contact name] on [Date] at [Hour.Minute when conversation window is opened].ichat" and the problem relates to the time stamp. It turns out Messages is indeed logging all conversations, but when a new conversation is initiated, a new log file is created with the old date and time stamp in the name rather than getting the current date and time and using that in the filename. This of course has the effect of overwriting the existing file in the directory because the names are identical.

If Messages.app is closed and then reopened, initiating a new conversation with a contact does not overwrite the log for the old one. However, the second conversation and all subsequent conversations will overwrite the previous log. Thus, if one has multiple conversations with one contact but closes the conversation window each time, the only log that will remain is the log of the newest conversation - but it will have the filename of the (now overwritten) oldest log.

Conversation logs are stored in folders for each day, and this also seems to have the effect of storing conversations in the wrong folders. What I observed is logs from conversations that occurred on, for example, September 15th, stored in the folder 2012-09-10, because that is the location of the log of the earliest conversation I had with that contact since Messages.app was launched.

If a Time Machine backup has occurred, then the old logs can be retrieved from backup and restored, then manually renamed with a proper time stamp. Messages then has no trouble parsing and incorporating the logs into its conversation history as it should (but is happy to overwrite them again if given the chance).

The only workaround I can figure out is to never close conversation windows until this is fixed, and if one does so without thinking, immediately relaunch Messages to ensure fresh log files are created the next time a conversation is initiated with that contact.

In sorting out this mess and retrieving my logs from backups, I have also discovered firsthand that Mountain Lion's QuickLook is severely broken and fails to display .ichat files at least 4 times out of 5 but will eventually display the file after repeated attempts. Spotlight also seems to be horribly broken, failing to return proper search results when disk images are mounted, failing to index disk images (even when they are read/write), and randomly reindexing the disk (and slowing the whole system down in the process; this occurs even after forcing the system to rebuild the entire Spotlight index).

Bug reports will be filed shortly.