PstFileAttachmentExporter : Export all file attachments from command line

[stephenjannin]


Export all attachments from a given pst file from command line. This tool is written in .net core for maximum portability and is using Xst Reader classes without the UI.

[Dijji]

I like this. I'm tempted to just merge it and cry hurrah!, good code, more functionality, excellent. I also love the idea of running the code on the Mac. There were remarkably few exclusions required to get there, too.

However, thinking a little more, it feels like a part of a bigger picture that needs thinking through even if we only implement this part of it. Otherwise we risk getting caught out with a particular piece that just does not fit into the whole in any coherent way.

How would this fit in to command line support for exporting email bodies with their attachments, with an attachment folder per email, which is what is available in the context menus today?

What happens to email threads where a document is being sent backwards and forwards being reviewed and changed? All the attachments would typically have the same file name. How does the user make sense of the collisions?

What happens if the user wants to know where a particular attachment came from? How do they trace it back to its source?

How would this work with large, sparsely populated folder structures such as are typical of .ost files? Most of the generated folders would be a) useless and b) empty. Should the command line allow the specification of the folders to be exported? Or should it just be that empty folders just not created?

Should the user be allowed to override the target export directory as part of the command?

What do you think about these questions?

Dijji

[stephenjannin]

Hello,

I was quite in a hurry to simply extract all attachment files from a 20Gb pst archive for my wife, and I had no time for extra checks : it does overwrite if a file with same name already exists, and I didn't put in place a real argument parser to specify the extract directory.
Probably the next steps that I could imagine :
1/ commit this proposition, and make further evolutions depending on the time you/I have
2/ create a shared library (in .net standard ?)

• in order to avoid the #if !NETCOREAPP (it's not nice from my point of view)
• to avoid files inclusions that can be confusing
• need to extract all UI sync and Windows specific usages (maybe with virtual functions that would be overridden in the WPF implementation)
  3/ handle the overwrite, target directory, improve traces, display stats etc etc.

As it's your project and I don't know what you have in mind, feel free to commit or not, and improve step by step.

[stephenjannin]

I finally removed the overwrite of existing files + fixed some unsupported directory names (ending with ' ', or containing invalid characters. The 20Gb archive is now well extracted :)

[Dijji]

I'm liking this better all the time!

[stephenjannin]

Sucessfully extracted a significant amount of attachments from archives. Finally files are overwritten depending on the message received date. We keep only the last one.

[Dijji]

I'm going to pull your code into a new branch called CommandLine, and make you a contributor in case you feel inspired to write more code.

The next two tasks will be:

• Work out the command line arguments for a single command line tool that will handle all export tasks, whether of emails, attachments or properties, possibly called XstExport.
• Create a revised solution structure of the sort you describe with a common project and a project per skin. Each satellite project will probably also pull in all common files, because the target platforms will vary, and I'm very fond of single file installations. However, as you say, conditional compilation should be kept out of the common files, perhaps in favour of a Xamarin-like interface mechanism where common code needs to access platform specifics. Initial satellites will include today's WPF UI, a headless Win32 DLL, a Win32 command line export tool, and a portable command line export tool based on your work. A branch of this base might be a WinUI version.

What you think?

Dijji

[Dijji]

FYI: I have finally incorporated your code into release 1.14, which includes command line support for exporting emails and properties as well as attachments, with some refinements, like being able to specify the source Outlook folder, and flatten the output into a single directory. It also contains a portable version.

Thanks again for your contribution, which is (mostly) still there.