FileReplacer exception handling and tmpfile cleanup #44
Conversation
…ensure tmpfile gets removed.
| // setup buffering, as almost certainly anywhere using this class is going to want this | ||
| BufferedOutputStream output = new BufferedOutputStream(new FileOutputStream(tempFile)); | ||
| // prepare directory structure | ||
| file.getParentFile().mkdirs(); |
There was a problem hiding this comment.
this also should be verified to ensure sanity
|
AFAIR, the reason in NX2 to leave tmp file in place was for easier recovery. Did not find any direct proof of this decision, but these are IMHO related issues: AFAIR, NX2 had a problem to kill some config files (staging.xml in this case), leaving 0 byte file in place, making it impossible to recover (with or without human intervention). Hence, we opted to leave tmp files as is to at least make human intervention possible/easier. |
|
@cstamas isn't that why we built the replacer, so that the new file wouldn't corrupt the old file. If we failed to write the new file, or failed to replace the new file, wouldn't the internal state be corrupted anyways? |
|
@jdillon yup, that is what I remember too. |
WIP, this does not yet pass tests due to one test explicitly assuming the tmpfile should remain on failure. Pending some use-case why this is good or desired.