Hello,
Version 24.6 added .Abort/.Cancel methods for long-running operations to MboxStorageReader.SplitInto:
Members for .NET Framework 4.5 and .NET Core Versions
SplitInto
token : A CancellationToken that allows for the possible cancellation of the operation.
Members for .NET Framework Versions Below 4.5
SplitInto
Cancel() : Description: Interrupts an ongoing split operation.
For PersonalStorage.SplitInto and PersonalStorage.MergeWith this .Cancel property is not added yet.
Can you please be kind and ask the developers if there’s any plan for this in the near future or the status of the case if ongoing?
I’m sure the implementation is so easy while the feature is crucial.
Thanks
The absence of .Cancel methods for PersonalStorage.SplitInto and PersonalStorage.MergeWith in the current version is likely due to prioritization of features in the development roadmap. The recent addition of cancellation support for MboxStorageReader.SplitInto demonstrates our commitment to enhancing user experience with long-running operations.
Solution
To address this, I recommend reaching out directly to our support team for the latest updates regarding the implementation of cancellation methods. Additionally, you can submit a feature request through our support channels, which will help us prioritize development based on user needs.
Next Steps
Contact Support: Reach out to our support team for updates on the feature request.
Feature Request: If you haven’t already, submit a formal feature request through our support portal.
Stay Updated: Monitor the release notes for Aspose.Email to see if this feature is implemented in future versions.
Please let me know if you need further assistance or have any other questions!
Thanks,
Just a Boolean .Cancel property to add and return / exit the loop operation once set to True!
And if you don’t mind, can you please add this suggestion to the case?
When using PersonalStorage.SplitInto, what is the equalivant of MboxStorageReader.MboxFileCreated event?
This should be fired each time a new .pst sub part is created on disk.
Just like PersonalStorage.StorageProcessed event, it is expected to have e.FileName parameter.
Do you find it useful to add?
@australian.dev.nerds
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): EMAILNET-41600
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
As we’ve mentioned previously, a new converter is currently under development, and it will support the features you’re asking about, including progress reporting and a cancellation mechanism.
We are planning to publish this new converter before the end of this year.
Regarding the .Cancel property, this approach is being reviewed, as it is mainly relevant for supporting compatibility with .NET Framework 4.0.
Well, thanks, please correct me if I’m wrong, but I think you simply consider Threading as an older .NET 4 thing and Async as a newer thing in .NET 4.5+
Even for .NET 4.8 projects I’d mostly use threading to execute operations concurrently on separate threads, potentially achieving true parallel execution on multi-core processors, async/await is not a replacement for threads in all cases.
And .Cancel boolean property is a very simple thing that can be done in no time
Thanks for your comment.
Just to clarify, we don’t consider Threading to be “old” or async/await to be a universal replacement; they solve different problems.
You’re right that for certain compute or parallel workloads, explicitly using threads or tasks may be more appropriate, especially when working with Thread, ThreadPool, or Task.Run to leverage multiple cores.
However, for I/O-bound operations or when dealing with async APIs, async/await provides cleaner, scalable, and more readable code, especially in UI and web apps.
As for the .Cancel boolean, yes, it’s simple in itself, but cancellation patterns require more than just a flag. If you want cancellation to be thread-safe and responsive, especially in complex workflows, it’s better to use CancellationToken or similar constructs that are already well-integrated into the Task-based async model.
Hello and thanks for the update, converting email formats in batch is typically CPU intensive, but can also involve significant disk I/O. While the conversion process itself relies heavily on the CPU to perform the necessary calculations and data transformations, the need to read from and write to disk for each email adds a substantial disk I/O component. So, the Threading is preferred to handle both CPU/Disk, since Async methods are usually not preferred for CPU intensive tasks.
And about the .Cancel complex part you’ve mentioned, just like MboxStorageReader.SplitInto .Cancel property it can be extended to PersonalStorage.SplitInto and PersonalStorage.MergeWith like this:
Internally, the source storage is being read and enumerate all its items in a loop, the first inner line of the loop can have:
If .Cancel = True Then Return or ThrowException or whatever!
Just one line, very thread-safe and simple on your part, and .NET 4.0 compatible
Thanks anyway
The ticket was created to extend cancellation support to long-running operations in PersonalStorage, such as SplitInto and MergeWith. The goal is to introduce support for cancellation across these APIs, in line with what already exists in MboxStorageReader.SplitInto.
We’re well aware that inserting a simple if (.Cancel) check in a loop is technically possible — but implementing cancellation properly, especially in a reusable and thread-safe way that integrates cleanly with the rest of the API, takes more than just dropping a line of code. That’s precisely what the ticket is for.
As for threading vs. async — yes, you’re right that CPU and disk I/O are both factors in batch conversion, and for CPU-bound workloads, traditional threading may be preferable. However, that discussion is separate from the scope of this ticket.
