“missing file” not quite missing?

[tjluoma]

I imported 25,550 .eml files from the zsh-users mailing list archive, which seemed to go fine, except for this one error message:

I’m not sure what was special about that file, but I checked and it existed in the folder as I would have expected, so I tried importing it into EagleFiler, at which point I got this message:

I assume this is just one of those “Don’t worry about it” situations (with a dash of “You imported 25,550 files at once and had 1 error? Be happy!”) but I wanted to make sure before I assumed

[Michael_Tsai]

It’s probably OK, but I don’t like mysterious errors. Is there a way to download those 25,500 files so that I can test this? I saw multiple archives at that link, but the files didn’t have .eml in their names.

Is anything about 1558.eml mentioned in the error log:

~/Library/Logs/EagleFiler/App Log.log

?

Do you recall whether you did the import right after opening the library? Or whether you tried to verify the library or move/rename a folder while it was importing?

[tjluoma]

This was a brand new library which I had just created to import these into (I am trying out creating my first ‘email archive’ and thought this would be a good test).

I created the new library and then I imported the folder with all of the .eml files in it.

Here is an archive of the exact folder of files that I imported. (I think macOS’ default Archive Utility app can deal with .tar.xz files… if not let me know.)

zsh-users.tar.xz

[tjluoma]

Here is the App Log.log file as an attachment:

eagle-filer-log.txt (2.4 KB)

[Michael_Tsai]

Thanks, I was able to reproduce the problem. As I suspected, it’s caused by EagleFiler trying to verify that the file exists (as it normally does shortly after opening a library) while the file was in a half-imported state (known to the library but not yet fully copied into place). I’ve fixed this for the next version of EagleFiler.

So, the error is actually harmless, but you can also avoid it by directly moving the files into the library folder and using Scan for News Files, and this is in general a faster way to do large imports.

Also, for a large number of .eml files, I recommend merging them after import, as performance will be much better with them in a mailbox instead of as separate files.

[tjluoma]

@Michael_Tsai

I’ve fixed this for the next version of EagleFiler.

Excellent! Glad I “hëlped”

@Michael_Tsai

So, the error is actually harmless, but you can also avoid it by directly moving the files into the library folder and using Scan for New Files , and this is in general a faster way to do large imports.

Ah, good to know. It did take quite a while to import, even on my M1 MacBook Air.

@Michael_Tsai

Also, for a large number of .eml files, I recommend merging them after import, as performance will be much better with them in a mailbox instead of as separate files.

Did not know that either, but will definitely check out the link and do so.

Unrelated, but sort of related…

I don’t suppose there’s any way to point EagleFiler at a Google group (say http://groups.google.com/group/bbedit for example) and have it archive all of those messages?

[Michael_Tsai]

@tjluoma

Ah, good to know. It did take quite a while to import, even on my M1 MacBook Air.

There’s also an importing performance regression in the current beta (fixed for the next one).

@tjluoma

I don’t suppose there’s any way to point EagleFiler at a Google group (say http://groups.google.com/group/bbedit for example) and have it archive all of those messages?

Not directly, but maybe one of the solutions here would help?

[Michael_Tsai]

@Michael_Tsai

Thanks, I was able to reproduce the problem. As I suspected, it’s caused by EagleFiler trying to verify that the file exists (as it normally does shortly after opening a library) while the file was in a half-imported state (known to the library but not yet fully copied into place). I’ve fixed this for the next version of EagleFiler.

This is fixed in EagleFiler 1.9.4.