Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'the CLI is not the issue...' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
the CLI is not the issue...
Authored by: mingking on Nov 26, '02 08:31:00AM

This program *only* runs from the command line. That is not the porting issue. The issue is that the format of the .pst file is written in little-endian format (being a M$ specification). The original author was most likely using an x86 box to run Linux, and therefore he wrote it with a little-endian view of the world. Since the PowerPC of the Mac is a big-endian processor, code running on it reads the file with all of the multi-byte values swapped (you might need to look up what big vs. little endian means somewhere). Code can be written to be endian-agnostic, but it is more work for the author, and unfortunately this code was not written that way. It *assumes* the machine that is running the code is running on a little-endian processor. (Note I am not dis-ing the author of libpst - he did a tremendous job reverse engineering the file format. That was a big job in and of itself.)

I spent a few hours trying to isolate the parts that need modification, but it just became too much for me right now. (not technically, just time-wise). Maybe some day I\'ll get a chance to continue the work, but no guarantees. If someone would like to collaborate on this, post here and let me know.



[ Reply to This | # ]
the CLI is not the issue...
Authored by: mdurell on Nov 29, '02 02:10:15AM

From the author's readme:

"The should now be runnable on big-endian machines, if the define.h
file is first modified. The #define LITTLE_ENDIAN must be commented
out, and the #define BIG_ENDIAN must be uncommented."

In other words, a quick edit to the define.h should be all that's needed.

I can say this about libpst:

Firstly, it's not really a lib. Maybe that's a component but the main programs are executables. In other words, no worry that you'll have to write your own C program to access the features of this software.

Next, it seems to work and it's fast too! I had just converted last night several PST files by doing the imap hack. Using libpst it was a LOT faster. I'm about to run it against a 600 MB pst file as soon as it's done copying off my slooooow USB drive. The caveat: YMMV.

I plan on finding all the misc pst files I have lying around and extract the mailboxes from it and run those through a custom perl script I wrote to copy messages into a folder based in the month and year in the timestamp of the message header. This means I'll have easy access to all my mail including the ability to grep directly in an open (doesn't get much more open than ASCII text) and human-readable format.



[ Reply to This | # ]
endianism issues
Authored by: mingking on Nov 29, '02 09:38:35PM

Awesome - big-endian support in libpst 0.4! That wasn't available back in October when I looked into this. I'm glad the original author went ahead and added that - when I tried to do it my head nearly exploded slogging through the complex data structures that make up a .pst file.

I built the new (0.4) code after resolving a few minor build issues, but the resulting tool didn't work on my .pst file. I have contacted the author about the remaining issues. It may be that my .pst file is just a version that he hasn't seen before. For others, it may already work on your files.

If you need help on building libpst for OS X (like I said, there were some minor issues getting it to build in the latest dev tools) let me know and I can share what I found. Or wait until the next official release and maybe the author will resolve those build issues as well as do whatever it takes to read more .pst file versions.

Isn't it great that us OS Xers are able to share with the Linux community?



[ Reply to This | # ]
the CLI is not the issue...
Authored by: tomaz on Nov 23, '03 08:58:44AM

If you apply this patch to libdbx 1.0.3, it will run correctly also on big endian machines (you must define BIG_ENDIAN as 1):

54,65d53
< void _cbo (unsigned char *a, int len)
< {
< #if BIG_ENDIAN
< int i;
< unsigned char ch;
<
< for (i=0; i<(len/2); i++) { ch=a[len-1-i]; a[len-1-i]=a[i]; a[i]=ch; }
< #endif
< }
<
< #define cbo(a,b) (_cbo ((unsigned char *) (a), (b)))
<
91d78
< cbo (&(signature[0]),4); cbo (&(signature[1]),4); cbo (&(signature[2]),4); cbo (&(signature[3]),4);
379d365
< cbo (&indexptr, 4);
387d372
< cbo (&itemcount, 4);
417,418d401
< cbo (&(tindex.self), 4); cbo (&(tindex.unknown1), 4); cbo (&(tindex.anotherTablePtr), 4); cbo (&(tindex.parent), 4);
< cbo (&(tindex.indexCount), 4);
434d416
< cbo (&(index.indexptr), 4); cbo (&(index.anotherTablePtr), 4); cbo (&(index.indexCount), 4);
484d465
< cbo (&(blockhdr.self), 4); cbo (&(blockhdr.size), 4); cbo (&(blockhdr.u1), 2);
501d481
< cbo (&(blockp.val), 4);
544c524
< ((FILETIME*)bufx) = &(email->date);
---
> ((struct FILETIME*)bufx) = &(email->date);
648d627
< cbo (&(hdr.self), 4); cbo (&(hdr.nextaddressoffset), 4); cbo (&(hdr.blocksize), 2); cbo (&(hdr.nextaddress), 4);
677d655
< cbo (&(hdr.self), 4); cbo (&(hdr.blocksize), 4); cbo (&(hdr.unknown2), 2);
681d658
< cbo (&(fol.id), 4); cbo (&(fol.parent), 4); cbo (&(fol.unknown6), 4);
747d723
< cbo (dest, 4);
750,752c726,727
< memcpy((FILETIME*)dest, &buffer[pos], 8);
< cbo (&((FILETIME*)dest)->dwHighDateTime, 4); cbo (&((FILETIME*)dest)->dwLowDateTime, 4);
< // DEBUG_EMAIL("[%d] value copied was %#X%X\n", __LINE__, (FILETIME*)dest->dwHighDateTime, (FILETIME*)dest->dwLowDateTime);
---
> memcpy((struct WIN32_FILETIME*)dest, &buffer[pos], 8);
> // DEBUG_EMAIL("[%d] value copied was %#X%X\n", __LINE__, (struct FILETIME*)dest->dwHighDateTime, (struct FILETIME*)dest->dwLowDateTime);



[ Reply to This | # ]
the CLI is not the issue...
Authored by: tomaz on Nov 23, '03 09:00:23AM

(apply the patch to libdbx.c)



[ Reply to This | # ]