Losing files with Dropbox

I’ve recently started using Dropbox to synchronize one of my EagleFiler libraries. I’m careful not to have the library open on both Macs at once, but I’ve noticed several times that files disappear from EagleFiler - they’re still on disk, but I have to reimport them and lose the metadata changes.

Has anyone else seen this? I’d be more inclined to blame Dropbox than EagleFiler, but I don’t really have any good ideas as to how to track what’s going on.

(It would sure be nice if EagleFiler would detect when unexpected files appear inside a library :slight_smile:

Are you using an encrypted library?

This is the first I’ve heard of it. It sounds like Dropbox is overwriting the .eflibrary/Contents.db file with an older version. Perhaps you could watch the activity on that file with fs_usage?

Yes, although in this case that would just obscure the metadata loss. :slight_smile:

bug still here, and i guess i know why
Hello,

I have the same issue, and i think i’found the issue.
It’s a conflict with Contents.db

  • When you add a file in eaglefiler, the file Contents.db is not instantly modified on your hard drive.
  • Instead new Contents.db will only be written on the hard drive when the eaglefiler library is closed. (stange but true)
  • As a result, if you use the same library synced with dropbox on 2 computers at the same time, you can reproduce this kind of scenario:
  1. computer 1 add file A to the library and doesn’t close it (=> Contents.db is not saved on dropbox and is not aware of the new file A). File A itself is uploaded to dropbox.
    2 Computer 2 add file B to the library and close the library = > Contents.db and File B are uploaded to dropbox.
    3 Computer 1 close the library and overwrite its Contents.db (which has been modified in the meantime at stage 2 to add a reference to file B) with a version only aware of file A, which is synced by dropbox.

  2. result: on both computers and dropbox, there’s the same library which contains files A and B, but whose Contents.db doesn’t have a reference to file B ! So file B doesn’t appear in Eaglefiler…

As a solution File B, needs to be reimported.
My problem is that i have many “file Bs” in the Files folder and i don’t know which one to reimport. I would need an automatic tool…

EagleFiler saves changes to the Contents.db after a few seconds. It doesn’t wait until you close the library.

This won’t be a problem if you follow the manual’s recommendation to only open a given EagleFiler library on one Mac at a time. To import files on multiple Macs, you can use the “To Import” folder.

Thank you for your answer. And thank you for this great app by the way :slight_smile:

EagleFiler saves changes to the Contents.db after a few seconds. It doesn’t wait until you close the library.

Well, this is not what’s happening for me… I confirm that, on my two macs (intel-10.6 using a library synced with dropbox), Contents.db is really only saved when i close the library, sorry… So i guess i’m encountering some kind of bug here.

This won’t be a problem if you follow the manual’s recommendation to only open a given EagleFiler library on one Mac at a time

I try to do so, but sometimes it can happens that i just forget to quit eaglefiler on a mac before switching to the other… And this wouldn’t be a problem if the Contents.db was saved continuously, which again is not the case for me :frowning:

By the way, I managed to find the lost entries by using the “Contents (me’s conflicted copy 2010-07-06).db” created by dropbox when the conflict occured.

How are you determining whether it has saved or not? Have you watched using fs_usage?

You wouldn’t have this exact problem, but you would likely have other problems. Either way, the database will be changing out from under EagleFiler, and that will have unpredictable and almost certainly undesirable results.