mhorbul/libpst

libpst clone of http://hg.five-ten-sg.com/libpst/

libpst's Issues

Libpst / Readpst able to open / convert PST?

Hi,

Downloaded libpst 0.6.70 and compiled and there are quite a few websites (however not this and neither the source) claiming that libpst can also use .OST-files.

However when I try to use this program with:
readpst -D -r -L 1 -d debug.txt test.ost

I get:
"Opening PST file and indexes.
Error opening File"

and debug.text gives me:
"pst_open libpst.c(353) unknown .pst format, possibly newer then Outlook 2003 PST file?"

I am guessing libpst does not support .OST-files and such an implementation is not possible?

Best Regards

Why internal library will not be able to use

I compile this file into the python libraries, import, but the import into, after open the PST files. But will not be able to use internal methods of the library. Don't know what's going on.

fatal error

Hello. I try to run this library and fail and fail and fail :D.

After a long installation phase (that were somehow successfull) I include the libpst.h but it runs into an fatal error. I wonder, what I do wrong:

/usr/bin/ld: /tmp/ccECH4bZ.o: in function main': main.cpp:(.text+0x53): undefined reference to pst_open'
collect2: error: ld returned 1 exit status

I search now for solutions, but nothing helps.

Are there people out there, that were successfully run this lib?

python performance degrades over time

I have an application which reads very large pst files. I noticed a degradation in performance over time. To demonstrate this, i took the test.py file and deleted the print statements, and added the following lines to print out a message every 500 "items":

count += 1
if count % 500 == 0:
      logging.warn("count = %d" % count)

The output starts off "reasonable" :

2017-07-25 12:15:49,746 count = 500
2017-07-25 12:15:49,910 count = 1000
2017-07-25 12:15:50,143 count = 1500
2017-07-25 12:15:50,432 count = 2000
2017-07-25 12:15:50,744 count = 2500
2017-07-25 12:15:51,138 count = 3000
2017-07-25 12:15:51,553 count = 3500
2017-07-25 12:15:51,998 count = 4000
2017-07-25 12:15:52,686 count = 4500

but then deteriorates:

2017-07-25 12:20:26,865 count = 47000
2017-07-25 12:20:32,875 count = 47500
2017-07-25 12:20:39,700 count = 48000
2017-07-25 12:20:45,640 count = 48500
2017-07-25 12:20:51,255 count = 49000
2017-07-25 12:21:00,353 count = 49500
2017-07-25 12:21:11,214 count = 50000
2017-07-25 12:21:20,816 count = 50500
2017-07-25 12:21:30,561 count = 51000

Is goes from taking less than 1/2 second per 500 messages to over 9 seconds.

Do we know why this is happening?

thanks

[meta, github] publish your hg-fast-export rules

Hi,

I've recently been working with some issues in ALT's libpst package, whereby I've been communicating with Carl Byington who maintains the upstream project in mercurial.

Since ALT's build system takes input in Git, I've started converting from Hg to Git in order to get fresh patches (and build packages).

I've discovered your github repo where you seem to do the same conversion. Several days ago, my result of conversion https://github.com/imz/libpst had a "merge-base" with yours. (Mine is reproducible with consecutive runs of hg-fast-export -r ../libpst/ from ) The divergence was at a commit where my converter has put carl <[email protected]> as the committer whereas yours has put [email protected] <[email protected]> (less human-friendly).

But now!.. Then you updated the conversion completely a few days ago, and the common merge-base is gone.

I don't want to have two different conversions on github, but since I'm going to run my conversion on my own, I'd like to know how to reproduce your results. So that we don't diverge.

Mine hg-fast-export is from a snapshot:

* Чт май 29 2014 Eugeny A. Rostovtsev (REAL) <real at altlinux.org> 0.1-alt9
- New snapshot (ALT #30005)