library lives on another disk but it filled up my main drive!

I am trying out your Eagle Filer software to archive a lot of emails (~20 Gigs worth) from Entourage 2004 on a 10.6 system. My main disk had about 16 Gigs free. I made a library, and imported a few emails to test it out. When I saw it was working well, and realized my library wouldn’t fit on the main drive, I quit Eagle Filer, moved the library folder to another (empty) drive, restarted Eagle Filer, opened the folder on the new drive, and began the import overnight. In the morning, I found that it quit complaining of a disk full, and indeed my startup drive was full! Does anyone know what it might have put on my main drive, while importing into a library on another disk - I can’t seem to find this 16 gigs worth of stuff. Where could it be?

thanks,

Mike

When capturing from Entourage (and a few other applications), there is no direct file for EagleFiler to import because the data is embedded in a database. Thus, EagleFiler first extracts the relevant messages and metadata and saves them as individual files in the standard Mac OS X temporary items folder. On my Mac, this is at:

/private/var/folders/EI/EIl9lvN-FCWaUN2P611rfU+++TI/-Tmp-/

I think it will usually be on the boot drive (not necessarily on the drive with the home folder or the EagleFiler library). By the way, I recommend OmniDiskSweeper to find (and delete) files that are unexpectedly filling up your disk.

After EagleFiler successfully imports the files into the library it will delete the temporary items. Additionally, Mac OS X will automatically clean up this folder from time to time. In this case, if you don’t have enough free space to hold all the mail that you want to import, you could try importing it in smaller batches.

I should also note, for completeness, that the temporary files for a library are almost always stored with the library itself (and for an encrypted library they will be encrypted). Capturing from database applications is the exception to the rule because the files are saved before EagleFiler knows which library they will be going into.

I see. Any way to change that (preferences or config file)? I don’t have enough room on my boot drive for what I want to do, and the library will live on a nice empty external drive. Can I ask EagleFiler to keep the temporary data it extracts on that drive also?

oddly, I tried it, and it didn’t find it.

You could override it by launching EagleFiler from Terminal with a command like:

TMPDIR=/Volumes/ExternalDrive/tmp /Applications/EagleFiler.app/Contents/MacOS/EagleFiler

I’m not sure why; that folder shows up in OmniDiskSweeper for me.

those are two separate lines, right? like

% TMPDIR=/Volumes/ExternalDrive/tmp
% /Applications/EagleFiler.app/Contents/MacOS/EagleFiler

is this for csh, tcsh, sh, bsh, etc.?

thanks!

Mike

It’s a single line for bash, although they’re probably similar enough that it would work for others, too.

indexing messages on 2nd drive makes my primary drive click like crazy

I did this, and now both my database and the temp files live on a different drive. But, when it’s Indexing a huge import I just did (showing Indexing in Activity window), the main drive is clicking like crazy, indicating a lot of activity. Why would it be touching my main drive if it’s already copied the stuff and is now just indexing it (supposedly) on the external drive?

Mike

You might be able to use the fs_usage tool to see which files it’s accessing. My guess is that nothing of consequence is being written to the main drive but that, as EagleFiler processes the HTML parts of the e-mails, Mac OS X is repeatedly accessing a Web cache file:

~/Library/Caches/textutil/Cache.db

It seems to do this even though EagleFiler has told it not to try to load anything.

is there anything to be done about this? I googled this file name but didn't see this problem talked about or how to prevent it.

thanks,

Mike

I don’t know of a way to prevent it. If you goal is to reduce activity on the main drive, you could perhaps replace the folder with a symlink to a folder on another drive (or a small RAM disk). This would at least let you see whether it’s that cache that’s causing the disk activity.