SaveAsync and CancellationToken support?

[sandreas]

Hey there,

Recently a tone issue pointed me to a problem in my code, but then I noticed this might be something that cannot be solved easily with atldotnet...

Since atldotnet does not have an async / Task based API, is there a way to ensure, that Track.Save does not break files, if CTRL+C is pressed, while saving? Or is this completely up to me?

I'm not an expert with Task, async and CancellationToken right now - I'm trying to get in, but it seems that killing the app via CTRL+C broke the filestream of this user somehow.

This line does the Track.Save, but I'm not sure, how to handle the CancellationToken in this case...
https://github.com/sandreas/tone/blob/main/tone/Commands/TagCommand.cs#L104

Additionally, I would like to ask, if you plan to support something like SaveAsync and CancellationToken someday?

[Zeugma440]

Thanks for linking the original issue.

Here we have a case where ATL doesn't perform well : I/O can be awfully long because the user is targeting a file sitting on a NAS. As you may have noticed, ATL always operates on the file itself to avoid losing time copying bytes to memory or to a second file.

As a consequence to that design, no writing operation can be gracefully interrupted.

If that is a requirement, you should definitely use a temporary file in the tone temporary folder. That might even speed things up a little compared to working on the NAS directly.

---

Regarding your question, someone already brought that up here : #115

=> It looks like there's a missing feature .NET doesn't support yet to enable ATL to do actual Async operations.

Let me also put my bottom line comment here

That being said, in ATL, there's a vast majority of operations that have to be done sequentially. Even operations that could be done in parallel (e.g. saving multiple tag systems on the same file - e.g. ID3v2 and APEtag) cannot be done at the same time on the same file.

=>There might be some performance improvements here and there, especially during read time, but don't expect a revolution. Fine-tuning the buffer size to your needs will have much more impact on I/O performance.

[sandreas]

Thank you for the detailled explanation.

Here we have a case where ATL doesn't perform well : I/O can be awfully long because the user is targeting a file sitting on a NAS.

Well, I think that ATL is just "killed in action" if you hit CTRL+C without handling this in the application gracefully and that should not be the case. So I think tone is handling this wrong atm.

As you may have noticed, ATL always operates on the file itself to avoid losing time copying bytes to memory or to a second file.

I think this is one of the main advantages of atldotnet over other libraries, because you can decide if it is necessary to create a new / backup file...

As a consequence to that design, no writing operation can be gracefully interrupted. If that is a requirement, you should definitely use a temporary file in the tone temporary folder. That might even speed things up a little compared to working on the NAS directly.

Ok, that is good to know. I think that stopping tone with CTRL+C or a kill / taskkill should lead to a graceful termination wherever possible to not break any files. Maybe I will introduce a command line parameter supporting kind of a --slow-but-safe-mode, where temporary files are created, but in my opinion this is not necessary, if the app terminates gracefully. If someone feels like doing a kill -9 or power his system off while tagging, then it should be clear that this IS possibly damaging files.

Regarding your question, someone already brought that up here : #115

Ok, I totally understand that. I just thought it would be a nice way of introducing CancellationToken to the write operations, but this seems to be tricky for binary stuff.

Great, this solved most of my problems. Thanks again for taking the time.

[Zeugma440]

Always a pleasure 😉