We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Can't open PST created with Aspose.Email for Java in Outlook 16 when file is larger than 4GB

Hello,

I am currently evaluating Aspose.Email for Java, by testing a server process that is creating a PST file containing a specified number of mail messages. The purpose of the test is to verify performance and compatibility. The server process completes with out any errors being reported regardless of the final PST file size.

However, Outlook 2016 can only successfully open PST files created by Aspose.Email for Java when the file is less than 4 GB in size. Once the PST file exceeds 4 GB, when the file is opened, Outlook aborts and then tries to recover the file.

Server:

  Aspose.Email for Java 6.2.0.0 with Temporary License
  Red Hat Enterprise Linux Server release 6.5 (Santiago) 64bit OS
  Java SDK 1.8.0_73 (64bit)

Client:

  Windows 8.1
  Outlook 2016

---- Windows Error (Japanese):

このファイルで見つかったエラー:

修復の必要なアイテム: 49495
見つからないアイテム: 0
フォルダーのないアイテム: 0

フォルダーのないアイテムは、保存先不明フォルダーに入れられます。


----

The result after recovering the PST file is 55,495 of 60,000 messages remain.

According to other posts, the Aspose.Email API does not impose a size limitation on PST files.

Is there a way to create PST files larger than 4 GB that Outlook 2016 can successfully open?

Sample Code being used:

package test;

import com.aspose.email.FileFormatVersion;
import com.aspose.email.FolderInfo;
import com.aspose.email.MailMessage;
import com.aspose.email.MapiConversionOptions;
import com.aspose.email.MapiMessage;
import com.aspose.email.PersonalStorage;
import java.util.List;

public class SampleMakePST {
public static void makePst(String filename, List emlFileList) {
PersonalStorage ps = null;
try {
ps = PersonalStorage.create(filename, FileFormatVersion.Unicode);
FolderInfo rf = ps.getRootFolder();
FolderInfo sr = rf.addSubFolder(“Results”);
FolderInfo sub = null;
MapiConversionOptions opts = MapiConversionOptions.getUnicodeFormat();
opts.setPreserveOriginalAddresses(true);
opts.setPreserveOriginalDates(true);
opts.setPreserveSignature(true);
opts.setUseBodyCompression(true);
int nextidx = 0;
int folderidx = 0;
int i = 0;
for (String emlFile : emlFileList) {
nextidx = i / 10000;
if ((sub == null) || (folderidx != nextidx)) {
folderidx = nextidx;
sub = sr.addSubFolder(String.format("%04d", nextidx));
}
MailMessage eml = MailMessage.load(emlFile);
MapiMessage msg = MapiMessage.fromMailMessage(eml, opts);
sub.addMessage(msg);
msg.dispose();
eml.dispose();
i++;
}
} finally {
if (ps != null) {
ps.dispose();
}
}
}
}

Hi Mark,

Thank you for writing to Aspose Support team.

We have investigated this issue with the latest version of Aspose.Email for Java 6.2.0 and sample messages at our end. The PST thus created opened fine in MS Outlook without causing any error. It seems to us that the issue may have arose due to the sample data set at your end. Please share your sample message files with us so that we can use these to create one such PST at our end and investigate the issue further.

Hi Kashif,

Thank you very much for investigating this issue.

I have found the answer to the problem: Corrupt PST File.

My setup is complicated. The Linux machine is a virtual machine running on Mac OS. The sample PST file was created in a directory shared between Linux and Mac OS. Both Linux and Mac OS generate the same checksum for the file. The sample.pst file was transferred from Mac OS to the Windows machine via a Remote Desktop Connection session where the shared directory is also shared with the windows machine.
Windows Explorer was used to copy the file from Mac OS to the Windows desktop.

Since it worked for you, I figured it should also work for me; therefore, something other than the file creation process must be wrong.

With that in mind, I discovered that for files less than 4GB, Windows Explorer apparently works fine; but, for files larger than 4GB, the file is corrupted some how. The copied file ends up being larger than the original. The MD5 checksum for the copied file is of course different from checksum of the original file on Linux.

Using a different method to transfer the file and after verifying that the MD5 checksum matched. Outlook was able to open the 4GB+ file without error.

The sample program and data used for testing have been attached to this reply as MakePst.zip. Please read the README.TXT file included in the zip file..

I am very sorry that I assumed that Windows could copy a file correctly without needing to verify the result and wasted your precious time checking this issue.

Again, thank you very much. Please consider this issue closed.

Hi Mark,

Thank you for sharing your feedback

We are always here to assist you further with respect to your inquiries. Please feel free to write to us if you have any other query related to the API. We’ll be glad to assist you further.