dropbox.cache muddying my organization waters

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. :slight_smile:

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…

Mike

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 will look into making EagleFiler ignore these files automatically, but you may be able to work around it now using the UnscannedExtensions default. You could also turn off automatic scans for new files via the ScanForNewFilesOnOpen esoteric preference.

Thanks, Michael. I’ll look into that.

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.

Mike

Since the main dropbox cache folder I want to ignore in EF is entitled

.dropbox.cache

I issued

defaults write com.c-command.EagleFiler UnscannedExtensions -array cache

I then shut down Dropbox and, via the CLI, moved that folder out of the EF library, and deleted that folder and it’s contents from EF.

I then moved the cache folder back, launched Dropbox again and re-scanned one more time in EF. The folder and its contents displayed once again in EF.

I also tried the above process with the following with no luck.

defaults write com.c-command.EagleFiler UnscannedExtensions -array dropbox.cache

Mike

Just needed a restart of EF to get it to work.

  1. stop dropbox
  2. move .dropbox.cache away from EF library
  3. delete reference to .dropbox.cache in EF
  4. issue:
defaults write com.c-command.EagleFiler UnscannedExtensions -array cache
  1. quit EF
  2. move .dropbox.cache back
  3. relaunch EF

Seems to have worked!

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?

They appeared to be related to the dropbox revisioning feature where it maintains older versions for retrieval if needed.

Haven’t seen that more than once so far. Will keep an eye on it and see if it recurs.

Mike

OK. I was under the impression that the Dropbox revisions were not in the folder and only available through the Web site. Has that changed?

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.

Regards,

Frank

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.

EagleFiler 1.5.1 will ignore the Dropbox cache files so that they aren’t picked up by scans.