Risk of corruption

[abique]

Hi,

I wonder how risky is it to save tags to an audio file.
What are the risks of corruption and what to do to reduce them?

Cheers,
Alex

[Serial-ATA]

Lofty has seen pretty wide adoption and over the years I've only gotten a few reports of corruption. Most cases come from storing very large items in Opus, which still doesn't seem to be entirely right. The best I can offer is to try it out and see how it works on your library, most people have no issues and all writes are at least decently tested for the most basic cases.

If you do encounter any issues with file corruption, just be sure to report it here. It'll very likely be one spurious file out of your entire library 😄.

[abique]

When you perform a full rewrite, how do you do it?
Do you create a temporary file, write it, then swap it with the original?
Do you have a verification step before the swap?

[Serial-ATA]

1. The tag is created in memory (with necessary verification done during this step)
2. The file is read into memory
3. The tag is replaced in the file in memory
4. Any offsets/sizes are updated throughout the file
5. The file is rewritten to the original location

Lofty is restricted to certain portions of the file when performing the writes, and it does quite a bit of validation on your data before even creating the tag. It is, by design, much more aligned with the specs than other tagging libraries to try and prevent you from shooting yourself in the foot.

[abique]

Thank you for the details.
So if the application crashes in another thread during 5., then the file might be lost is that right?

It isn't a big issue actually. If I'd want to be extra safe, I could run the write operation in a child process do it on a copy of the original, then do the rename + unlink after some verification: read the metadata and make sure they are what I expect and hash the decoded audio and make sure it is the same as before.

[Serial-ATA]

Yeah, if for some reason something were to go wrong while it's writing then the file wouldn't be recoverable. That's why we try to do every bit of processing we can beforehand to minimize that risk.

[abique]

Thank you very much, this discussion was very helpful :-)

[uklotzde]

It is always the responsibility of the application to decide into which file metadata is written back. This could either be the original file or a temporary file. It is also the responsibility of the application to decide if and how to apply post-write validation/verification before replacing the original file.

Ideally, Lofty must never leave behind a corrupt file. That's the expectation. But it would be naive to assume that this won't happen (again) in the future. Lofty is still young. Nevertheless, I consider it the best in class for Rust.

TagLib also suffered from file corruption bugs in the past.