Nested Folders in "Files"

Should EF be looking down into a nested folder structure that’s copied into the “Files” folder in a library, or does the Files folder need to be flat? I’m copying a bunch of mboxes into Files, and EF is complaining about “Missing File” in the Errors window. I also get an IOerror 21.

Hitting Reveal takes me to the folder that contains the file, rather than the file itself. The files in question are 4 levels deep (i.e. Files->Active->Home Mac->Mailboxes->mbox file).

Thanks for the help, and let me know if it would be better to be emailing questions rather than posting here.

You can have a nested folder structure, but you should not rearrange it via the Finder or EagleFiler will lose track of where the files are and think that they’re missing.

You can e-mail questions to eaglefiler@c-command.com.

Thanks for sending more information. There’s a bug (which I’ve fixed for the next version of EagleFiler) that will lead to a Missing File error if you use Scan for New Files to import a folder/file that EagleFiler must transform before importing. For example, you were importing an Apple Mail legacy/archive .mbox folder/package. With a normal import, EagleFiler will convert this to a standard mbox file and import that. This is not possible when you drag the package directly into the Files folder in the Finder, because in that case you are telling EagleFiler to import exactly that folder; it would be rude for it to try to change the folder that you specifically put there.

Secondly, it’s not a good idea to import legacy/archive Apple Mail .mbox packages into EagleFiler. This is because although they contain files that look like mbox files (and EagleFiler will do the best it can with them) Apple Mail does not actually generate them in the standard mbox format. In rare cases this can lead to missing messages. Instead, you should import from Apple Mail using the capture key. Then EagleFiler itself will generate the mbox file, and it will make sure that it’s written properly.

What I’m trying to do is use a nightly file sync to bring the latest mboxes from 4 different machines together for a searchable index, so the capture key isn’t an option.

I’m looking for some way to just have it automated so that the latest set of files is imported and indexed when I get into the office in the morning. If I use “Import Files…” I end up with the folder structure being duplicated in Records each time I sync and import (i.e. Test, Test-1, Test-2, etc.).

Short of the current version’s issue with non-standard mbox files, and the problem with the occasional missing email (which for my application is probably OK), is syncing directly in the Files folder the best approach?

What is the source of these .mbox packages? Are you syncing with a computer running an old version of Mac OS X?

I’m not sure what you mean. You could import just the file (view the menu command or AppleScript) without the extra layers of folders.

Syncing the folder is not a good idea if it will involve replacing mailbox files that EagleFiler has already imported, or moving/renaming/deleting other files out from under EagleFiler.

The source is Mail 4.5 on Snow Leopard. I’m just copying the .mbox files directly from Mail’s folders (i.e. Library/Mail/Mailboxes).

If I import just the files, and I have 4 files named “Inbox”, will EagleFiler have a way to know that they’re 4 good files and they all need to be saved and indexed, or can it only have one file called “Inbox” at the top level of Records at a time? And if that works, wouldn’t I end up with “Inbox-1” thru “Inbox-n” as I repeatedly import every night?

I got the idea that syncing .mboxes that had changed would work from the manual: “It’s fine to use software that copies folders quickly by only copying the files that have changed. An example of this is SuperDuper’s Smart Update feature. Such software works great with EagleFiler because it copies data in only one direction at a time. You end up with the same result as if you’d done a regular copy, but it doesn’t take as long.”

The files would just be updated with changes (if any) from the previous day, so no moving/renaming/deleting (well, I suppose they are technically deleted and rewritten…).

That’s odd. I don’t think I’ve ever seen Snow Leopard create mailboxes in that format.

Right.

The manual is talking about copying/syncing an EagleFiler library. Your situation is different because you are copying files that aren’t in a library into the library.

That is in general fine for any type of file except for mailboxes. EagleFiler does not consider mailbox files to be editable. This is for performance reasons and also because changing the messages in the mailbox might cause EagleFiler to lose track of the metadata that it’s storing for them.

This is fixed in EagleFiler 1.5.6.