Each time I start EagleFiler 1.15, it goes through a multi-minute process of Loading Dates, Indexing Notes, and Indexing Records. Nothing has changed (this happens when I simply quit and relaunch EagleFiler). BTW: I have the “scan for new files on startup” option turned off (i.e., manual scan, only).
I don’t know if this is relevant, but my library contains in excess of 8,000 records stored on Dropbox (0.8.114). Thanks.
This sounds normal. The indexing process is checking the files’ modification dates to see whether you’ve edited any of them outside of EagleFiler (in which case it would need to update the index). So if you haven’t changed anything this should be pretty quick. It will depend on the speed of your hard drive and whether other applications are accessing it at the same time as EagleFiler. EagleFiler also checks to make sure none of the files in the library are missing. This all happens in the background, so it doesn’t prevent you from doing other things in EagleFiler.
I would guess there is extra overhead from doing the indexing on DropBox. Working on an EF library that resides on DropBox might be a bad idea for other reasons as well. See the top post at http://literatureandlatte.com/forum/viewtopic.php?f=2&t=5295.
I’m not aware of any extra overhead reading from a folder shared with Dropbox, and I don’t think the package issue affects EagleFiler. You should, however, follow these guidelines when using Dropbox.
Bad guesses on both counts, then. Sorry.
What is the point of indexing
This really has nothing to do with Dropbox (turned it off).
Every time EF starts up (no file activity between invocations and scanning for new files turned off), it goes through a five to seven minute process of “Indexing records”.
I thought the idea behind indexing is that it doesn’t need to be done every time. Shouldn’t only “new” records require indexing (e.g., on scan or import). I am curious why this activity is performed each time EF is launched.
Thanks.
Once a file is indexed, EagleFiler doesn’t index it again unless it changes. At launch, EagleFiler checks to see whether any files were modified since their last indexing (because, e.g., you can edit them without using EagleFiler). This is the activity that you see. It’s not clear to me why this is taking minutes for you. What kind of Mac do you have, and what drive is the library stored on?
Indexing - MacBook Pro
I have a relatively new (< 1 year) MacBook Pro with the standard internal drive. The library consists of about 14,000 records. No other program is running or modifying these files. The attached screen capture is from the Activity window.
Is the library encrypted? It’d like to take a closer look at what the indexer is doing on your Mac. It would be helpful if you could open the Activity Monitor program and select EagleFiler in the list. While it’s indexing, choose Sample Process from the View menu. Then save the resulting data to a file and send it to me.
Sent you the Activity Monitor capture…
and no, the library is not encrypted.
Thank You!
I want to personally and publicly thank Michael for helping me resolve this issue.
It turns out that I had a good number of photos with bad EXIF data (modification dates in the year 2022). The file system then dutifully set the file modification dates to the metadata EXIF modification dates. Therefore, EagleFiler was always reindexing these files (as it should) since it thought they had been changed.
What’s important to note here is not so much what the problem was - but that Michael worked with me and, with verbose logging turned on, let me track down the issue.
There are very few software vendors that will a) pay this amount of attention to an issue that it turns out had nothing to do with their software and b) have the capabilities in place with excellent logging to help track down these type of things.
Thank you for absolute first-class service. I’ve tried DEVONthink, SOHO Notes, Together, Yojimbo (oh, you want nested folders?), and others. EagleFiler stands head and shoulders above them for my needs.
Frank
If, in a multi-user Dropbox scenario, different files are edited simultaneously, are there risks associated with syncing of the different indices?
This is safe because the indexes are managed by EagleFiler, and if you follow the guidelines there will only be one copy of EagleFiler accessing them at once.
So, once one does as the guidelines indicate:
After editing your library with one Mac, make sure that both it and the second Mac have fully synced with the Dropbox server (that is, the icon in the menubar no longer shows spinning arrows) before opening the library on the second Mac.
it is ok to have both EF installations open with each user editing different files. Is that correct? I was concerned that the interaction of Dropbox and the two EF installations might result in a perpetual update cycle for the indices.
In any case, given that some index files are not small (one of mine is already 200 MB), would it make sense to allow users to make an alias of the index file where the latter is put in a folder so that it can be excluded from Dropbox?
I’m not quite sure what you’re asking here. You can edit files directly from any number of Macs at once. You should only open the library in EagleFiler on one Mac at a time, and you should make sure it’s fully synced as described in the guidelines.
The contents of the .eflibrary package are managed by EagleFiler, and you should not go in there and change anything manually. Replacing an index file with an alias will not work. However, Dropbox is supposed to detect and transfer only the parts of the files that have changed, so even if the index file is 200 MB it’s unlikely that you would be transferring that much over the network.
If DropBox implements a file-exclude facility (as their user poll requests), and each user excludes the EF index, would that allow each user to simultaneously have the same library open?
[Should’ve added] The reason I’d like to do this is that EF >> Finder, even if operations are limited to 1) viewing records with their metadata and 2) editing different files on the respective Macs.
Also, I wasn’t intending on editing the eflibrary package.
No, because EagleFiler uses the Contents.db file to track the files and metadata in the library, so that needs to stay up-to-date on all the Macs.