Error while loading a PST file

Hi,

I am using the java api version - aspose-email-3.6.0-java. My requirement is to take a input pstfile - extract the message - add a header to each message - create a new pst file and add all the messages.

Since the pst file is not decreasing in size when deleting messages, I am creating a new pst file.

Now while adding messages to the new pst file if the process is terminated - I want to start from where it left. So I have created a text file and added the list of message entry id to the text file and I check before adding each message to the new pst file.

Now if the destination pst file already exist ( means process is terminated abruptly), if processed normally pst file would have been added to the ZIP file and it will be deleted.

So if the PST file exist _ I am loading from the file else I create a new file but while loading the PST file which was half processed - Api throws the below exception. I cannot delete the PST and recreate the PST file since that will increase the processing time and a PST file may contains thousands of messages.
I have attached the PST file for your investigation.

Code:
if(!destPstExist){
destPst = PersonalStorage.create(dest.toString(), FileFormatVersion.Unicode);
}else{
destPst = PersonalStorage.fromFile(dest.toString());
}

Exception while loading from file

java.lang.RuntimeException: Header CRC is not valid !
at com.aspose.email.gW.j(Unknown Source)
at com.aspose.email.gW.b(Unknown Source)
at com.aspose.email.gW.(Unknown Source)
at com.aspose.email.et.(Unknown Source)
at com.aspose.email.hN.(Unknown Source)
at com.aspose.email.PersonalStorage.a(Unknown Source)
at com.aspose.email.PersonalStorage.fromFile(Unknown Source)
at com.aspose.email.PersonalStorage.fromFile(Unknown Source)
at com.batch.uidinjector.UniqueIdInjector.pstToPST(UniqueIdInjector.java:585)

Please let me know how to resolve this.

Hi Satish,

Thank you for contacting support team.

I have tested the sample PST file and tried to open it in Outlook but could not succeed as Outlook gives error “Errors have been detected in the file” and does not open it. Similarly Aspose.Email throws exception “Header CRC is not valid” due to errors in PST files.

I tried to re-produce the issue by following the steps as given below:

  1. Create PST
  2. Create custom folder
  3. Load EML
  4. Convert to MapiMessage
  5. Add MSG to customer folder
  6. Close the PST
  7. Open the same PST again
  8. Access the custom folder
  9. Add some MSG again
  10. Close the PST

It is observed that no exception is raised by Outlook or Aspose library, while processing same PST multiple times in the following sample code.

In your scenario, as you have mentioned that your process terminates abruptly, so the PST file format may not remain intact which causes Outlook and Aspose library to throw exception. Therefore, it is suggested that you may please try to terminate the thread until and unless the last activity, say adding a message, is completed and PST file is properly disposed off. It will cause the PST file format to remain proper, and hence it will not raise exception while opening the same PST next time.

Following is the sample code which is used to create and reuse the PST file without any exception.

PersonalStorage pst = PersonalStorage.create("D:\\Aspose\\newpst3\\Sample.pst", FileFormatVersion.Unicode);
FolderInfo testFolder = pst.getRootFolder().addSubFolder("Test");
MailMessage mail = MailMessage.load("D:\\Aspose\\newpst3\\Test.eml");
MapiMessage mapi = MapiMessage.fromMailMessage(mail);
testFolder.addMessage(mapi);
pst.dispose();
PersonalStorage pst2 = PersonalStorage.fromFile("D:\\Aspose\\newpst3\\Sample.pst");
testFolder = pst2.getRootFolder().getSubFolder("Test");
testFolder.addMessage(mapi);
pst2.dispose();

Please feel free to write us back if you have any other query related to Aspose.Email. We will be glad to provide you assistance as soon as possible.

Thanks Kashif Iqbal!


When the process is terminated abruptly, code for disposing the pst files won’t be executed. I have implemented a shutdown hook listener but it won’t be called when the operating system is shutting down.

can’t the pst files work normally when it’s not disposed? otherwise I have to recreate the pst files and add all the processed messages. Please let me know how this can be resolved.

Hi Satish,


The PST files work fine if the process terminates properly which disposes it. However, when a process is terminated abruptly, as I mentioned earlier the PST may not dispose properly and the structure may not remain intact. In that case, you may consider assigning high priority to such process which may force user to properly shut down the process before the station shuts down.

In order to get further confirmation about this issue, I’ve requested development team’s feedback and will write back here as soon as there is some information available in this regard. Your patience is highly appreciated until then.

Hi Kashif,


Under normal conditions the pst files will be disposed and it doesn’t throw exception when it’s reloaded but I also have to handle the abnormal conditions like system shutdown, process terminated abruptly etc.
When this happens and the process is restarted - the process should resume from where it left off.

So if the process is terminated in the middle of processing a PST file, pst file won’t be disposed properly.
Is there any way to commit the message in the PST file as soon as it’s added?
I also observed the PST file size remains zero when the messages are added only after disposing the file size shows value. I think if there is a method to commit the messages as soon it’s added then the structure may remain intact.

Also the performance of processing the PST file using the API is slow. Earlier using EML files I was able to process 100 messages ( eml files per second). The performance of processing PST files is 15 messages per second. Even extracting a message from a PST file and adding a message to a PST file is taking considerable time. Extracting message - 6 to 100 milli secs ( average 20 milli secs )
Adding a message to PST file - 25 to 125 milli secs ( Average 30 milli secs). Please let me know how the performance can be improved. I am using java api version 3.6

Hi Satish,


We have thoroughly discussed the issue to handle the corrupted PST due to interruption while adding message halfway. A ticket is logged to investigate the possibility to provide this feature under ID:NETWRKJAVA-33343. Development team will analyze it and share their findings with us. We will write back here as soon as some feedback is received from the developers.

Performance for handling the PST can be increased by creating PST in memory and then flushing the memory on regular interval to write the data on disc. It is observed that writing a message to PST is far less time taking than IO operations to write data on disc. Could you please give a try to the following sample code which creates PST in memory and then writes messages to it?

static void CreatePSTAndAddMessageToPST()
{
ByteArrayOutputStream BAoutput = new ByteArrayOutputStream();
PersonalStorage pst = PersonalStorage.create(BAoutput, com.aspose.email.FileFormatVersion.Unicode);
try
{
pst.getRootFolder().addSubFolder(“TestItems”);
FolderInfo folder = pst.getRootFolder().getSubFolder(“TestItems”);
MapiMessage msg = new MapiMessage("from@domain.com","to@domain.com", “Subject”, “Body”);
folder.addMessage(msg);
}
finally
{
pst.dispose();
FileOutputStream fos = null;
try
{
fos = new FileOutputStream(“Output.pst”);
fos.write(BAoutput.toByteArray());
fos.flush();
fos.close();
}
catch (java.io.IOException e)
{
e.printStackTrace();
}
}
}

Hi Satish,


I would like to update you about the status of NETWRKJAVA-33343 ticket that is linked to this thread. Our development team has thoroughly investigated this issue and we won’t be able to provide the fix for this issue in the near future. When messages addition to the PST is interrupted halfway, it gets corrupted and restarting the messages addition is impossible without pst recovery. At present, Aspose.Email doesn’t support recovery of corrupted pst and hence we won’t be able to provide an ETA for provision of fix for this issue.