file overwriting should be clear

[craigsteffen]

The file overwrite policy should be clear in the usage.

Also, any errors encountered should be very explicit, and even non-errors. Particularly, these should be called out at the parfu level so that they do not generate MPI_File_Open errors.

• create mode, in non-overwrite-archive mode, user specifies archive file that already exists
• create mode, in overwrite mode, user specifies file that exists, code should confirm
• extract mode, in non-overwrite mode, some target file exists, code should complain before extracting ANY files.
• extract mode, in overwrite mode, code should confirm there are files that will be overwritten.

[craigsteffen]

I need to roll this into the template for how version 0.6 will work.

I just read this. I don't think we want to try to mirror the fancier features of tar in this respect.
https://www.gnu.org/software/tar/manual/html_node/Dealing-with-Old-Files.html

For a default create, parfu should first check to see if the specified archive file exists. If it does, it should exit immediately with an error.

For parfu create, if the target file exists but the "overwrite" has been invoked, then the file will overwritten with no errors thrown.

For parfu default extract, if any file exists matching the name of a file to be extracted, then parfu will throw an error and exit immediately.

For parfu extract with the "overwrite"

[craigsteffen]

Now looking at this during the 0.6 build-up:
I think the extract is clear. If the extract is going to put a file on disk, but there's already a file there, there's a question what to do.

But for the create case, what's the worry? parfu isn't designed to add to archives, it just creates a single archive. It's not supposed to do progressive backups; that's not its schtick. However, I suppose with weird linking, it could get in a situation where a file was going to be archived twice, which I supposed should be flagged or mentioned because it's going to create an ambiguity upon extraction.

I need to think on this more.