I was trying to import some old (V3) local Apple Mail folders. I just grabbed them from ‘~/Library/Mail’. The folders failed to import with:
OSError: error 20 (Not a directory) for file: SOMEMBOX
and a bunch of individual (all?) emails resulted in
EagleFiler encountered the error “ValueError: invalid literal for int() with base 10: ''” while importing “._410648.emlx”. This message may be damaged. EagleFiler will skip it and continue importing the other messages in the mailbox.
I sorted the .mbox errors by just doing
find . -type f -name ".*.mbox" -exec rm -rf {} \;
And I gather I should do the same for this hidden .emlx files. Any ideas?
I think I see what’s happening here and will address it to prevent these errors in the next version of EagleFiler. However, removing the ._ files should also fix the problem. These files are used to store metadata (e.g. for the resource fork) on file systems that don’t natively support such features. They’re not needed for importing into EagleFiler because the mail data is in the data fork.
However, it’s a bit of a mystery where the metadata files came from because I don’t think Mail has ever attached metadata to these files. Nor are they typically accessed by the user to manually add metadata. Also, the Mac boot volume has normally always supported multi-forked files, so even if there were metadata I wouldn’t expect to see it broken out like that. I wonder if maybe it was added by Time Machine and you had later used a file copy/sync tool that was not metadata-aware.
Ok, I looked into this further and you’re right. I was copying this stuff from an old computer and it seemed faster to move it using a SSD drive which is exFAT format. Sure enough the .XXX.mbox and .XXX.emlx files were not in the the original ~/Library folders but were created in the SSD. You learn something new every day…