It seems like checking that option has been presented as the solution to a couple of recent issues. Why is it a user option and not just a system default? In other words why does KoLmafia not save unconditionally on changes?
I have some vague memories that the original implementation relied on some Java file I/O to be reliable across operating systems and it turned out that was not the case. Even under normal shutdown conditions, sometimes cached data did not get dumped to disk. So the flag was introduced to work around that.
Why should it be an option today? If people have really, really slow disks, I can imagine disk I/O having a noticeable impact. If people are using SSDs I can imagine they want to minimize writes to preserve disk life but if that is really something KoLmafia should support then we should probably revisit sessions logs as well. But those feel like niche cases to me.
So should changes be written to disk immediately and unconditionally?
I'm thinking yes and then wondering if there are some alternatives to Java Files to be investigated. How wrong am I? ;-)
I have some vague memories that the original implementation relied on some Java file I/O to be reliable across operating systems and it turned out that was not the case. Even under normal shutdown conditions, sometimes cached data did not get dumped to disk. So the flag was introduced to work around that.
Why should it be an option today? If people have really, really slow disks, I can imagine disk I/O having a noticeable impact. If people are using SSDs I can imagine they want to minimize writes to preserve disk life but if that is really something KoLmafia should support then we should probably revisit sessions logs as well. But those feel like niche cases to me.
So should changes be written to disk immediately and unconditionally?
I'm thinking yes and then wondering if there are some alternatives to Java Files to be investigated. How wrong am I? ;-)