Closed GoogleCodeExporter closed 9 years ago
Hi,
I don't suppose you would be able to provide the PST files for review?
Unfortunately I don't have access to any 32bit PSTs created with ExMerge to
test with.
I can only really think of running the files through SCANPST to make sure it's
as clean as possible, unfortunately the library isn't very forgiving with
invalid pointers to child objects or attributes.
If you are keen, you can hack around to find the Hex of the object that's
throwing the error and shoot that through if it's not too sensitive.
Richard
Original comment by rjohnson...@gmail.com
on 24 Dec 2010 at 1:04
I'm looking for one PST with errors I can share.
Meanwhile I've used the demo of this tool
(http://www.diskdoctors.net/outlook-pst-recovery/software.html) to repair the
PST. And it worked. The PST passes the test flawlessly...
The PST is actually broken.
Original comment by Piccini...@gmail.com
on 24 Dec 2010 at 2:32
Hi,
Even i got the same issue. This happens using 97-2002 data file. The same mails
works properly with 2010 pst files.
Original comment by manish.b...@gmail.com
on 12 Jan 2011 at 7:04
Getting more deeper into the code, i found that when the numberOfRowsPerBlock
is 64, the 65th mail throws error since it has entryValueReference as 0.
How to get into the next block?
Original comment by manish.b...@gmail.com
on 12 Jan 2011 at 10:00
Hi!
I assume you've checked the PST with scanpst, and that outlook has been
closed cleanly?
Moving on from that, each node is spread across a number of blocks in the
PST file and this is read transparently by the block input stream. Also
within each node's data there are block boundaries where the node data
ends, there is some junk data, and then it starts again in the next
internal block. The library does have some code to try and align this
reading, and indeed it has seemed to work for the most part, but it may be
that there is a special case in this instance where the block boundary is
incorrect or non existent, so the bytes it is reading for the 65th
entryValueReference are misaligned or non-existent.
To help, it would be great if we could get the PST file. Failing that a Hex
dump of the node in question should be sufficient for me to look into it
further.
Original comment by rjohnson...@gmail.com
on 12 Jan 2011 at 10:19
In PSTTable7C, if we change the code to:
HashMap<Integer, PSTTable7CItem> currentItem = new HashMap<Integer, PSTTable7CItem>();
// add on some padding for block boundries?
if (currentValueArrayStart>=blockSize) {
currentValueArrayStart=currentValueArrayStart+(numberOfKeys-1)*(currentValueArrayStart/blockSize);
}
byte[] bitmap = new byte[(cCols+7)/8];
//System.arraycopy(rowNodeInfo, currentValueArrayStart+TCI_1b, bitmap, 0, bitmap.length);
rowNodeInfo.in.seek(rowNodeInfo.startOffset+ currentValueArrayStart + TCI_1b);
rowNodeInfo.in.read(bitmap);
//int id = (int)PSTObject.convertLittleEndianBytesToLong(rowNodeInfo, currentValueArrayStart, currentValueArrayStart+4);
int id = (int)rowNodeInfo.seekAndReadLong(currentValueArrayStart, 4);
then, it works for 97-2002 format.
But then it doesn;t work for latest pst.
Can you help me change code such that it works for both?
Original comment by manish.b...@gmail.com
on 12 Jan 2011 at 11:56
rjohnson.id.au I can send you a pst file to reproduce the error. It's a pst
from my customer so I can't attach it here... My email address is info [at]
mauropiccini.it, contact me so I can give you the file.
Original comment by Piccini...@gmail.com
on 12 Jan 2011 at 2:38
Sure! Thanks for this.
I'm at work atm, but will try and have a look on Friday and see if we can't
get something that aligns the blocks correctly for both file types. We may
even have to pass a pst type flag through if worst comes to worst.
Original comment by rjohnson...@gmail.com
on 12 Jan 2011 at 2:48
I have fixed this issue. I will soon give it back to you. The issue is with
blocks. The way 97-2002 pst blocks work is different from newer pst.
if (currentValueArrayStart>=blockSize) {
currentValueArrayStart=currentValueArrayStart+(numberOfKeys-1)*(currentValueArrayStart/blockSize);
}
this works for 97-2002 format and the trunk code works for new formats. I have
just added another if loop which will check the psttype and based on that, make
calculations for currentValueArrayStart.
Original comment by manish.b...@gmail.com
on 17 Jan 2011 at 5:40
I would like to be an active committers. I am working on making the whole
libpst abstract and this library can call back a predefined class and can
return mimemessage for each mail in pst. I am working on that and would like to
contribute the same.
Original comment by manish.b...@gmail.com
on 17 Jan 2011 at 5:45
Always happy to welcome contributions!
Feel free to open issues for your changes and attach patches/code to them for
incorporation.
Thanks,
Richard
Original comment by rjohnson...@gmail.com
on 17 Jan 2011 at 12:50
I am attaching one java file PSTTable7C.java. This change will allow to work on
all kinds of pst.
I am also working on converting pst mails into MIMEMessage. I will soon share
those too.
Original comment by manish.b...@gmail.com
on 22 Jan 2011 at 6:54
Attachments:
[deleted comment]
[deleted comment]
Hi I have patched you PSTTable7C but still it give following error on
if currentValueArrayStart is 8176 .......... Unable to find 512
Need your help
Original comment by skkchoud...@gmail.com
on 2 Feb 2011 at 2:38
Send us the pst that is throwing the error. I have executed it lot of pst and i
never got this error again.
Original comment by manish.b...@gmail.com
on 3 Feb 2011 at 6:29
hi plz find at attachted
Original comment by skkchoud...@gmail.com
on 3 Feb 2011 at 10:14
Attachments:
Change it to
if (rowNodeInfo.in.getPSTFile().getPSTFileType() == PSTFile.PST_TYPE_ANSI) {
if (currentValueArrayStart >= blockSize) {
currentValueArrayStart = currentValueArrayStart + (4) * (currentValueArrayStart / blockSize);
}
} else {
if ((currentValueArrayStart % 8176) > 8176 - TCI_bm) {
// adjust!
// currentValueArrayStart += 8176 - (currentValueArrayStart % 8176);
currentValueArrayStart += blockPadding;
if (currentValueArrayStart + TCI_bm < rowNodeInfo.length()) {
continue;
}
}
}
This will make your pst work.
Original comment by manish.b...@gmail.com
on 3 Feb 2011 at 3:18
okay, I've committed this fix to SVN.
Original comment by rjohnson...@gmail.com
on 3 Feb 2011 at 6:00
Is this fix working properly?
Original comment by manish.b...@gmail.com
on 4 Feb 2011 at 3:58
Ya.... its working......
thank you so much............. it was great help for me :)
Can i have document link for the PSTTable7C.java class
Original comment by skkchoud...@gmail.com
on 4 Feb 2011 at 1:10
Could you please give any clue how to read mail from Exchange server... by
connecting MAPI protocol......
I can read mail through pop3/imap protocal but javamail doesn't support mapi
protocol...
Waiting for positive reply
Original comment by skkchoud...@gmail.com
on 4 Feb 2011 at 2:07
Hi,
Sorry, MAPI doesn't really have much to do with the PST File format.
Original comment by rjohnson...@gmail.com
on 4 Feb 2011 at 4:13
Original issue reported on code.google.com by
Piccini...@gmail.com
on 23 Dec 2010 at 10:51