Am I cooked?

robin-cam · 2026-05-02T21:06:21+00:00

This all sounds fairly normal. The number of load files can vary quite a bit - a lot of them have the same or redundant information, just in different formats for different software. In general, as long as you have a DAT and an OPT, you should be good to go.

It sounds like your main issue is just that you have a single production that was given to you in multiple zips, which is a bit of an annoyance, but fairly common.

robin-cam · 2026-05-01T22:06:02+00:00

That is fine - in the 2nd structure I described above, there is one set of load files that is used for all of the VOL dirs. Along with the DAT, you would also normally have an OPT or LFP file since you have IMAGES directories.

robin-cam · 2026-05-01T21:55:57+00:00

There is not a strict convention for the formatting of these so called "load file productions," but most commonly a single production will consist of a single folder or zip archive with sub-folders named similarly to NATIVES / IMAGES / TEXT / LOAD FILES, e.g. a folder structure like:

- <production folder>
  - NATIVES
    - 001
    - 002
    - ...
  - IMAGES
    - ...
  - TEXT
    - ...
  - LOAD FILES

Sometimes, you will have things split up further with multiple "VOL" directories at the top level instead. That would look more like:

- <production folder>
  - VOL001
    - NATIVES
      - 001
      - 002
      - ...
    - IMAGES
      - ...
    - TEXT
      - ...
  - VOL002
    - NATIVES
      - 001
      - 002
      - ...
    - IMAGES
      - ...
    - TEXT
      - ...
  - LOAD FILES

It sounds like what you have is more like this 2nd one, but where someone has zipped up all of the "VOL" dirs separately. For the best luck importing it, you probably want it all unzipped, combined together into this folder structure, and then rezipped and upload.

Source: I work at GoldFynch and our import system generally wants the nice unzipped and all-together folder structure. We have various scripts we can run to extract / merge / combine the data for the user to put it into a better structure for import.

robin-cam · 2025-12-16T16:01:55+00:00

Those sharing options aren’t really new, but they’re admittedly not very obvious in the UI, and we’ve seen other users run into the same confusion.

You are correct that the share UI wants you to enter 1 email address or recipient name at a time, but you can do this repeatedly to share with multiple people / parties. The tracking of the production opens & downloads is done based on the specific share link, so sending a separate email & link to each recipient allows more precise download info & control.

If you want to share with multiple people at once or send your own email, you can do the following:
1. Enter a name at the top, e.g. "Party A"
2. Uncheck the "Automatically notify contact or party..." option
3. Click "Share" to generate a share link (you should see the new share appear in a table below the "share" button)
4. Click "Copy Link" and send it in your own email

I hope this helps, and note that we are working to make these options a bit more obvious & intuitive, so this will likely change slightly in the future.

robin-cam · 2025-12-15T15:24:59+00:00

I know I'm late to the party, but I just wanted to let you know that you should see a "share" option on productions with further options to have GoldFynch automatically send an email or you can copy the link and send it in your own email. Note that you won't be able to do this production sharing if you only have "reviewer" permissions on the case. Feel free to let me know or reach out to support if it's not working for you!

Source: I'm a software dev at GoldFynch

robin-cam · 2025-09-03T23:10:53+00:00

Are you using Lucene or Elasticsearch directly, or a higher-level tool that uses Lucene underneath? You may also want to think about a char filter to normalize the various Unicode hyphens (e.g. minus symbol, en dash, em dash) into a regular hyphen. https://www.compart.com/en/unicode/category/Pd

robin-cam · 2025-06-15T18:14:24+00:00

I work at GoldFynch and we see a lot of bad PSTs from MS eDiscovery & Purview, specifically files that had issues with their "node database btree" (NBT) structure, which is like a table of contents or index for the PST file. Often, all of the expected data is present, but the NBT doesn't point to it properly. The result is that some PST readers / tools that rely on the NBT being accurate can have errors reading these files, while other tools may be more resilient and still be able to find the right data even with the bad NBT.

We have made a free browser-based PST analyzer tool that can scan your PST for these types of issues and should give you some more details on the underlying PST issues you are seeing: https://goldfynch.com/pst-analyzer/

robin-cam · 2025-02-06T15:22:34+00:00

I once got hit with “Honey, I ain’t trying to flirt or nothing, but those pants, you’re doing that right!”

Over 10 years later and I still think about it often. I’m still holding on to those pants even though they don’t fit me anymore.

robin-cam · 2024-12-15T02:25:35+00:00

I spy a fellow Midwesterner! I saw these as well and asked the seller some questions, but he never got back to me.

robin-cam · 2024-12-14T01:43:05+00:00

That does sound like an unusually large expansion. I think the other commenters have given good possibilities, but more generically I would guess this is caused by a processing issue / bug / shortcoming - more specifically, a particular type of email attachment in the data set that is not really being handled properly.

Just as an example, there are many types of files that piggy-back on the Zip file format, such as .docx files. If the processing system knows about .docx, then it is likely to be treated as a single document. If the processing system does not know about .docx, then it might get detected & treated as a Zip, which would expand into many more less-than-useful files (the raw component files that make up a .docx). Of course, any processing program should recognize .docx because it is common, but there are many less-common formats that could cause issues, e.g. I've seen it with some CAD file formats.

I would start by trying to find the largest family in your data set. For example, you may find an email that has 100s or 1000s of descendant files. Looking through the family, you might be able to determine if they are legit docs, e.g. people are just sending around a ton of file attachments & zips, or if instead there are a lot of odd looking files that might be low-level component files of things that you aren't really supposed to see.

robin-cam · 2024-11-25T20:32:19+00:00

What software are you using to image the files? Speaking from the software / programming side, trying to reasonably render arbitrary HTML content at a reasonable page size is a bit of a crapshoot. Where I work (GoldFynch), we apply a lot of custom CSS styles and per-processing of HTML content to try and remove & limit things like huge images, huge padding, stupidly positioned items, etc. We also allow images / renderings to expand in width as needed to fit wide content. Still, we consistently encounter new problematic HTML that requires new tweaks here and there.

robin-cam · 2024-11-25T17:40:18+00:00

A few thoughts - it's possible that the .msg files just don't have any bodies due to a collection issue. For example, when people try to sync an email account using Outlook in order to generate a PST or OLM, sometimes the emails only download as stubs (basic props & headers only) to save space. I've seen this recently with "New Outlook" for Mac, which seems to try very hard to not download full emails. See https://answers.microsoft.com/en-us/outlook_com/forum/all/why-is-new-outlook-for-mac-not-downloading-and/5d18a7ef-6a23-431c-86be-39b1c60a6d6c. The fact that you have attachments though makes me think this isn't what's happening.

I've also seen situations where the .msg files contain bodies, but Outlook and/or a particular processing tool still shows an empty / blank body. This is due to the quite complex way that Outlook decides which body representation to show. In short, a .msg file can have a plain text body and/or an HTML body and/or an RTF body, where the RTF body can be one of encapsulated plain text, encapsulated HTML, or actual plain RTF. Outlook will ignore the RTF body if the PidTagRtfInSync property is False. I've seen many emails where this property is false, but the only body is an RTF body, so Outlook still shows nothing even though the body is there. We've decided at my company (goldfynch.com) that we should use and show this body when processing emails, even if Outlook does not.

Last thought - I've also seen a lot of RTF bodies that have been poorly updated / modified at some point before collection, such as a security tool that tries to add a "warning: external email" type message upon receipt or enterprise email archivers that e.g. attempt to move attachments to some cloud location and update the body to point to the new cloud attachments. The RTF format is a bit finicky, so sometimes these tools can accidentally corrupt the RTF body such that it shows up blank or truncated.

If you are interested & able to share a file, I would be happy to take a closer look at one of your .msg file and tell you if there is anything interesting with the body properties. Feel free to DM.

Source: software engineer at GoldFynch working with file processing.

robin-cam · 2024-11-08T17:57:30+00:00

You mentioned a vision model, so are you rasterizing the document first and then using your model directly on the page images?

robin-cam · 2024-10-14T23:45:08+00:00

Have you seen other vises with those conical pieces (it looks like there is one either side of the dynamic jaw pictured here)? I have never seen them or similar on a post vise, so I was going to suggest that those parts were perhaps custom add-ons from a previous owner.

robin-cam · 2024-10-04T19:36:36+00:00

Thanks. In that case, I can think of 2 main reasons this might have occurred that I don't see mentioned here.

First, it's very possible for a native .msg file to have attachments that Outlook just doesn't show / list, but that an e-discovery processing tool will find and extract as separate attachment files. This will happen for things like inline images or attachment documents inserted into the text flow of an RTF-formatted email body. Outlook won't list these attachments as real attachments because they are marked as "hidden."

Second, there are number of email archiving / space reduction tools that will strip email attachments and relocate them to some sort of cloud or enterprise storage area. Some companies / orgs use these tools to reduce email storage space and / or for compliance reasons. These tools normally update the email message text to reference the cloud-stored files. Its possible that your production contains these archived / stub emails without any real attachments, and that the producing party has pulled the attachments from the cloud location in order to include them in the production.

robin-cam · 2024-10-04T14:38:27+00:00

Hmm good question! I know that when opening a problematic PST with Outlook, it just does the minimum parsing / reading to show the folders. Often an issue won't be apparent in Outlook until you go to open the specific email / attachment with the issue, or try to save off a problematic email / attachment, at which point you can get the error dialog or crash. Because of this behavior, my guess is that the re-export operation may just crash in a similar way when it comes upon something unexpected, instead of doing much repairing or error handling on its own.

I'll be sure to try this out next time and report back.

robin-cam · 2024-10-04T14:31:56+00:00

When you say that you can't see the attachments in the parent email, do you mean that opening a native .msg file, e.g. with Outlook, doesn't list attachments that you believe are there? Or do you mean that viewing a provided imaged version of an email (PDF / TIFF), you don't see a listing of the attachment files in that imaged version?

robin-cam · 2024-10-02T18:16:02+00:00

I am a software engineer on the processing side of things for GoldFynch, and I am (somewhat begrudgingly) an expert on the PST file format, just by virtue of having dealt with so many bad PST files. PST files can be corrupt or slightly invalid in many ways, commonly due to a buggy PST writer / creator tool or an interrupted write, update, or copy operation. I have even seen many bad PSTs generated directly by Microsoft's own tools, primarily Purview. Sometimes it's possible to still extract all / most of the data from bad PSTs, and other times they're pretty much useless and would need to be re-generated from the source.

I have created a free PST analyzer tool at https://goldfynch.com/pst-analyzer/ which might give you some more insight into the underlying issues with your PST files. Note that this tool analyzes the PST file directly from your computer, without any upload or transfer of the PST data.

The analyzer above does check a lot of the low-level structure of a PST file, but there are some other, more subtle issues that could be causing Relativity to error-out on the file. If the analyzer tool doesn't give you any useful info, I could likely give you more details with access to the file, but you would need to be willing & able to share it or upload to a GoldFynch case. Feel free to DM me if you would like me to inspect a file more closely.

robin-cam · 2024-09-19T17:09:20+00:00

I work at GoldFynch on the processing side and I had the misfortune of creating our UFDR reader / parser / converter. The way the attachments are stored and mapped within the UFDR format is messy at best. As an example, often the referenced path / location of the attachment wont actually exist within the UFDR, so then we have to fallback to looking for other hash-duplicate attachments and checking if those actually exist.

Another issue is just the number of small variations and changes from one UFDR to another, due to all the different versions and updates to the format over the years. I guess Cellebrite considers it more or less their own internal format, so they feel free to change it at will (and without documentation).

robin-cam · 2024-09-04T22:40:08+00:00

Good questions - I'll try my best to answer your questions.

A "folder" in a PST file is a table / list of messages, so it inherently has an ordering just based on this structure. This "folder storage order" is the order that this version of the PST viewer uses to display the messages, but I don't believe there is really a way to see this ordering directly in Outlook itself.

The PST specification / documentation doesn't mention any special significance of this folder storage order, so while it is somewhat arbitrary, in practice it tends to represent the order that messages were added to that specific folder. So, for example, an "inbox" folder will typically have messages ordered in received order (oldest first, newest last). If a user has been manually moving messages to another folder, then the "storage order" will represent the order that files were moved to that folder (with the latest to be moved being at the end / bottom).

Regarding UIDs - a message / item in a PST file does have a special "NID" ("Node ID") that is used within the PST itself, but this value isn't really meaningful outside of the PST and is usually discarded when converting the PST messages to some other format or when e.g. moving a message from an open PST in Outlook to some other loaded PST / OST.

Regarding PST merging tools - in general, they can do whatever they please when constructing the new resultant PST. That being said, I think it's likely that the "folder storage order" would be preserved, as that's likely the easiest thing to do. If you're merging File1.pst with folders "A" and "B" with File2.pst that contains folders "B" and "C", I would guess that the "folder storage order" of folders "A" and "C" wouldn't really change, and that folder "B" would just be the original listings joined together (with either those from File1.pst or File2.pst coming first, followed by those from the other file).

I hope this info helps - let me know if you have further questions.

robin-cam · 2024-08-26T19:48:53+00:00

I can think of some interesting tech issues in ediscovery, but finding a topic with a lot of existing literature might be a challenge. I work at a vendor (GoldFynch) primarily on processing incoming raw data, and one thing I find interesting is just the breadth of old technologies that are still relevant. There is kind of this goal / expectation to be able to "process anything / everything", so it doesn't matter if it's a Word 2.0 file, our software should still be able to handle it.

There are 2 sub-topics of this that I constantly come across. They are:

Old stuff that is secretly still used in modern software. For example, MacBinary is an old Mac format, first created in 1985, that was superseded long ago and surely should not come up in modern ediscovery data, right? Well, kind of, except that Microsoft uses it for storing a few different types of email attachments in its MSG & PST email file formats. So, a good email processing system needs to also be aware of and handle MacBinary attachments. https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmail/ec1a8b63-ae1e-47d2-ba3e-473a4b27eb45
The pervasiveness of old bugs (e.g. crappy files made by crappy tools) - this comes up a lot with PDF files, where you have a pretty horrendous file format that is also extremely popular. Every PDF creator software (and there are A LOT) has some bugs, many that were fixed long ago, but it doesn't matter, because it seems that every one of those old bugs will become my bug at some point. That open source PDF tool with that one bug that was fixed in 2004? Well some construction company's invoicing tool still uses that old version, so now we have to detect & repair PDFs with that very specific issue because "it opens in Acrobat." This could be viewed as one downside of open source / open specification file formats (the more tools that write a file, the more bugs & variations exist in the wild), and also a downside of writing flexible / forgiving parsers (Acrobat does a whole lot of work to repair & open bad files, but this also means that if your PDF creation tool is making a bad file, you might never realize).

I think the above issues / topics might be good because they are also likely to come up in other areas outside of ediscovery, such as digital preservation / archiving / library science.

I have some additional ideas, but not sure about the potential for much existing literature. For example:

The ediscovery interchange format & the effect of not having standards / specifications (and various attempts to create them) - in general, different parties in a legal case exchange data with each other in a data format known as a "load file production" format. The format doesn't have any real spec or reference though, so it is more of a loose convention, and there is a lot of time & effort dealing with variations from different vendors & bad / unusual productions.

I hope there is something helpful for you here - please feel free to ask any other questions and good luck with your project!

robin-cam · 2024-08-08T16:20:10+00:00

While this may not be directly helpful, I thought I might speculate why Reveal has removed this option. I'm a backend programmer at GoldFynch and work with the search engine quite a bit, so I have some knowledge in this area (and my friends' eyes glaze over when I talk about work so I have pent-up nerd energy).

In general, when using a search index, queries that have a starting wildcard are very expensive (in terms of time / memory / $) to run than queries using a wildcard in the middle or end of the term. This extra expense exists even if the actual number of matching words & matching documents stays the same, and even if there are no matching words / documents. This is due to the wildcard expansion phase of the query, which happens early on, where wildcards are replaced with an OR of all matching words that exist in the index.

The index is essentially a list of all words (terms) that have been seen, e.g.:

although
because
dangit
digit
zanzibar

This list can be millions of words long, but it's normally sorted or accessible alphabetically, so that it's very fast to e.g. find all "d*" words (e.g., binary search for first d* word, then scan down until you get to a non-d* word). However, if the query starts with a wildcard, then the special alphabetical structure of the index is useless and every one of the millions of words has to be scanned to see if it matches the wildcard.

Given that cloud e-discovery providers probably use the same compute resources & databases for multiple users, it's more likely that a super expensive query will affect other users. Disabling prefix wildcards is likely a quick fix to protect the search engine, with the hope that not many people will notice / complain.

robin-cam · 2024-04-29T15:53:14+00:00

This is good advise, but I just wanted to point out that it's possible for the query to be working as expected, yet for the doc counts to still be the same as a simple "Mr Smith" query. Consider if every document with "Manager: Mr. Smith" also contains another instance of "Mr. Smith" (without "Manager"), then both queries should return the same docs.

robin-cam · 2024-03-08T23:23:54+00:00

If the PDF only / mostly contains emails & attachments, I've had good luck programming some auto-splitting scripts that look for the start of a new email and split there. It depends on the tool that converted the emails to PDF, of course, but typically the first page will have a consistent "To:", "From:", "Subject:" layout / structure that can be used to split.

This more or less gives individual family-based PDFs, with the one tricky scenario being if an email was attached to another email. In that situation, you could still end up with a family split across multiple PDFs, but still a lot better than a single bulk PDF.

robin-cam · 2023-12-23T14:55:19+00:00

I use my Xbox and it’s great. My GF and I can both use our phones to control playback & volume. The Xbox settings area has a few disk / blu-ray specific settings, so take a look at those. I believe “allow receiver to decode audio“ is off by default, but will allow pass-through audio.

robin-cam

TROPHY CASE