inconsistent behavior around overwriting files

[Teque5]

I came across this while writing the BLUE file converter.

If you do meta.tofile('whatever', toarchive=True) and a whatever.sigmf archive already exists it doesn't write anything. I think this should raise an exception.

If you do meta.tofile('whatever') and both whatever.sigmf-dataandwhatever.sigmf-meta` exists it will overwrite the metadata but not the data file.

Basically we need to make the behavior consistent and raise exceptions if the files exist.

[gregparkes]

I think in the case of calling SigMFFile.tofile() on a .sigmf-meta and .sigmf-data pair, if either data or meta or both exist, then the default should be to raise an exception, but to enable overwriting, a new parameter such as overrides=True would enable the overwriting of existing files without complaint.

[Teque5]

Devils advocate:

Our tofile() was created to copy np.tofile, and the behavior of the numpy version does overwrite.

[gregparkes]

A valid point, however:

1. numpy.tofile() is not intended as an archive format (whereas SigMF is), and is intended as a "quick storage of array data" (https://numpy.org/doc/stable/reference/generated/numpy.ndarray.tofile.html)
2. the behaviour of unexpectedly overwriting/deleting existing SigMF metadata (which may be painfully extracted, think an over-the-air trial) for I/Q signals outweighs the risks (IMHO) of not following the NumPy API's behaviour.

[Teque5]

I completely agree on both items.