Out-of-memory errors can be destructive

[Hunter-Github]

...unless the user uses backups. Multi-gigabyte stuff can be tricky (lost one XXL-sized file this way, fortunately an intermediate result though), so I would add some words of caution into the help screens/README, viz. after the following passage:

"File operations are done atomically, so interruptions never leave a previously existing file truncated or partly edited."

insert this:

"Users must be careful when processing very large files with --at-once option turned on."

[jlevy]

Ah, that's unfortunate and certainly not the intention! Before changing the docs I'd like to know what your issue is exactly. Do you have details or a way to reproduce?

Look at repren line 335-346: If it was out of memory or out of disk on a giant file, it should abort before modifying the original. Do you know what path you were on and if there was a transform happening? What happened to your .orig file?

[Hunter-Github]

I'll be doing a bit of testing in the coming days and will come back with details or close the issue as no-repro. Thanks for the suggestion re: using the source. Was using repren in a pipe, saw no .orig lying around after the crash, suspect PEBKAC on my side.

[jlevy]

Thanks. If it's used as a pipe there can be no .orig backup since the program won't have the file name. But in that case it also shouldn't be modifying the original, either, so that doesn't explain a destructive outcome.

[Hunter-Github]

No repro so far. Closing.

[jlevy]

OK. It's important for repren to have essentially zero data-destructive issues for everyone to have confidence in it. If you do find/identify a data loss issue please reopen with details.