After updating to EF 1.5 and it syncing against my disk contents, it found a mess of versioning files (they appear to be) dropbox maintains. They didn’t show up before as < EF 1.5 didn’t update against the disk.
It’s an awesome new feature and I appreciate it greatly, but this large series of folders in the .dropbox.cache hierarchy is getting in my way.
Continuing to poke around for details on hiding this or whatever, but haven’t yet found anything yet. Is there a workaround?
For that matte, and I realize this isn’t EF’s problem, but I wish I could exclude files from dropbox sync too. I don’t need to see EF per-folder hidden files when I browse my dropbox with my iPhone.
Going to do some research into that possibility now too! I don’t recall there anything in the DB prefs about it, but who knows what lurks in the hidden prefs…
Found some details on the dream to exclude items from DB sync… they have implemented a by-folder exclusion in a recent beta build (I had an older beta build without this), but still no way to exclude by filename pattern, etc. Bummer.
I’m seeing another quirk with EF and DB that seems to arise when DB manipulates any directory that is syncing and/or a file is added/removed and all of the iterations of the file that DB has kept around get purged.
EF throws up the error window with a log of the missing files/folders.
The first time this happened it gave me quite a start and I had to figure out the slew of errors were not related to actual files I cared about.
Are you still seeing this problem? You should be waiting until Dropbox has finished syncing changes from the other Mac before opening the library in EagleFiler. What files are there that are being deleted that were not deleted through EagleFiler?
Temporary Files
I too am having issues with EagleFiler and Dropbox but by using Sonar (a file system monitoring tool) I have been able to get some clarity on what is happening.
On startup, EagleFiler creates a “Temporary Items.nobackup” directory with a per-session subdirectory. The activity in this subdirectory is quite substantial (at least in my case with thousands of archived emails in mbox files).
Dropbox, therefore, dutifully senses all of these file changes and tries syncing them all - or at least as best it can trying to keep up.
A suggestion: Since these temporary files are truly part of the “session” and not the “library” proper, would it not make more sense to keep these in a “tmp” directory? (Much in the spirit of other Unix-like programs that don’t put temporary files in the actual program data [library] locations.)
Thanks for your attention to these issues. I know you can’t possibly envision all use-cases that may crop up but having a Dropbox library seems to be a common theme around here.
What’s the issue? It doesn’t seem to me that it would be a big deal if Dropbox didn’t keep up with the temporary files. Perhaps there’s a way to make Dropbox ignore .nobackup folders?
Temporary files associated with the library need to stay with the library because for an encrypted library they need to be encrypted with the same passphrase, and because there might not be enough free space on the drive with the temporary folder.