Provide A History File Separate From The Log

[JimmyTheSaint]

I've complained about how the history has been difficult to use in 1.4 and 2.0. If everything just works, however, there's no real need to ever bother with history. In fact, I believe Syncthing doesn't have history at all, which is quite unsettling at this stage of development. But history is the ultimate safety net for when things go wrong, and is an essential sanity check if you ever lose faith. So perhaps history is more of a feature for geeks than the average user. In that case, why not maintain a history file in the same place as the log, but separate from the log, which contains way too much info?

 

When faced with a restoration session (my only real use for history), I'd much rather refer to a txt file than the history window because bookkeeping is much easier that way. For example, in the past 18 months, I've done 8-10 restoration sessions after old-replaced-new episodes arose due to faulty interactions among my peers (usually the Linux client's btsync starting up hours or days after a reboot shut it down). In 1.3, using the history tab as an index to restore stuff from the archive is usable, but a bit of a pain to follow because the history tab automatically updates and scrolls after each file is manually replaced. Providing a history file would make that much easier, while maintaining a safety net that stays out of sight and out of mind until needed. In fact, I haven't had to do this in quite some time (knock wood) because negative reinforcment has made me much better at remembering to manually restart my Linux NAS's btsync. The main UI's history window would still be useful for monitoring the most recent entries, I suppose. But it's not really all that useful to me because you can't leave it open as a real-time monitor like 1.3--it has to be manually refreshed by closing and re-opening it.

[RomanZ]

@JimmyTheSaint

 

History is stored in separate file starting from 1.4. Please see the "history.dat" file in storage folder (though, it is not text format - it is bencoded).

[JimmyTheSaint]

OK, but I just tried reading history.day with Ultima's BEncode Editor, and it's basically useless for reading history this way to do the necessary bookkeeping to verify if anything's been lost and to restore stuff. We either need a history reading utility that will make history as readable as in 1.3 or a conversion utility that will convert history.dat into a ledger that can be used in case of a disaster or a suspected problem.