xiph
Zero-byte files left behind when trying to flac.exe out of subset
1.4.2 for Windows, the file is CDDA so that -b8192 is out of subset.
Scenario 1: flac -fb8192 file.flac Result: Leaves zero-byte .tmp,fl-ac+en'c . At least it tells me what file I failed at.
Scenario 2: flac -t file.flac flac -fb8192 file.wav Result: Overwrites file.flac with a zero-byte file.
Expected: at least in the last scenario, it should throw error and do nothing at all?
At least part of this is fixed in #506
Could you check with a recent binary from https://hydrogenaud.io/index.php/topic,123176.msg1027870.html#msg1027870
That one leaves no trace.
Although I am not sure if it is wanted behaviour ... ? Maybe it is in line with what flac -f file.wav does otherwise, which is (I think?) delete file.flac first and then do whatever comes out of it. Most likely a user who gives flac -f
I'm unsure whether fixing this would be an improvement.
As far as I know, currently, using -f always results in the deletion of any file that has the name of the intended output file. I could take a look at the code whether it is possible to delay the removal of that file until as late as possible. That would 'solve' a few cases like this, but then behaviour isn't as consistent anymore: it is no longer clear when the file will be removed and when it will not be. An error during initialization might be 'caught', but an error during encoding itself will not be. For a user, it is no longer clear what to expect.
Furthermore, in the specific case you mention, it is reasonable to assume the user will try again, overwriting the file anyway.
I'm also not sure, so maybe this issue can be closed as completed.
But - luckily! - the following isn't correct:
As far as I know, currently, using
-falways results in the deletion of any file that has the name of the intended output file.
Not always. Not upon recompression - then source isn't deleted until target is done. (And please keep it that way.)