@John: That's exactly what I was testing this morning :) I'd like to see the fix backported, but want to ensure I understand the impact. To do so, I've been attempting to reproduce the original bug. However, using the test approach in the patch merged to master against stable/newton produces a totally different behavior than the one described in the bug. Specifically, the first rotation returns successfully but fails to rotate anything, and all the keys that appear on disk are fine. Subsequent rotations result in OSErrors that prevent any further rotation, which would be a totally different bug. In between each rotation attempt, I can validate that all key files on disk contain valid keys, each are non-empty, and more importantly, the keys don't appear to change. No empty key files are ever created when flush() raises an IOError. Any suggestions?
@John: That's exactly what I was testing this morning :) I'd like to see the fix backported, but want to ensure I understand the impact. To do so, I've been attempting to reproduce the original bug. However, using the test approach in the patch merged to master against stable/newton produces a totally different behavior than the one described in the bug. Specifically, the first rotation returns successfully but fails to rotate anything, and all the keys that appear on disk are fine. Subsequent rotations result in OSErrors that prevent any further rotation, which would be a totally different bug. In between each rotation attempt, I can validate that all key files on disk contain valid keys, each are non-empty, and more importantly, the keys don't appear to change. No empty key files are ever created when flush() raises an IOError. Any suggestions?
See the patchset in #13 for an illustration.