Posts from new forum members do not appear until they have been approved by a moderator; this is to prevent spam.
Instead of creating the symlink in the Files folder, first create the new folder from within EagleFiler. This will establish it as a folder that EagleFiler should scan. Then replace the folder with the symlink.
Well, this doesn’t accomplish what is desired
So, this is a bit of a visual hack, but doesn’t work if the symlinked folder contains sub-folders.
All of the content within the symlinked folder is uploaded to Dropbox. That means I am storing everything twice.
What I want is that the EagleFiler database only contains indexes and metadata and doesn’t contain any of the actual content files themselves, which as I pointed out already exist within dropbox.
So, this is not accomplishing what I want, which is to avoid duplicate storage. Because everything does get stored again in Dropbox, it is tediously slow because Dropbox is uploading (via its sync) everything that it already contains.
This is even true for the top level symlinked folder, which contains a handful of content files.
So, this is really a non-starter unless I’ve missed some other trick.
So, it would appear that the only real way to accomplish what I described without duplicate storage is to forget the symlink altogether.
Just have EagleFiler import everything while the dropbox app IS NOT LOADED or with syncing temporarily disabled.
After EagleFiler is done and all of the content copying is done and verified (!), then with fingers crossed, delete the original source folders.
Now, everything would be intact and in Dropbox with only one copy. But with the minor difference that the top level of the content folders is now within the <EagleFilerMydatabase>/Files folder. I guess that is not so terrible if I were really starting from scratch.
It is a nuisance as I have much content already organized as I want it to be organized.
I was considering switching from Devonthink to reduce complexity. But, there are real reasons for DevonThink’s complexity. It has a real “index in place” and don’t move anything feature. It anticipates the storage duplication problem and creates the somewhat poor UI for “sync files” that allow the database indices and metadata to be stored on dropbox, but not duplicate on each syncing client machine. So, it can do the job much, much faster. All at the real cost of a particularly nasty UI.
Different trade-offs. I am not sure I can really trust EagleFiler’s approach as it really has to put the content into its own “scope.” An understandable implication and functionally OK if I were starting from scratch.
You’ve been very helpful. Let me know if I am misunderstanding other aspects of this but I can tell from looking at my Dropbox account via the web UI what is happening.
The instructions also ask you to move the subfolder that already exists in EagleFiler before you create the symlink. That said, I will try to make this clearer in the next version of the manual.
That is correct, and it does work in general. You just won’t get the special behavior of following a folder symlink. (The reason for this is that people were inadvertently moving in folders that contained symlinks that they did not intend to have followed. So, at least as a short-term solution, I chose to make your advanced use case require explicit action in order to make the more common case “just work” for users who don’t even know what a symlink is.)
It really does work in that EagleFiler references everything through the symlink, including subfolders, and they are only stored once on your Mac.
I think you are right that Dropbox does not understand symlinks and so it will store everything twice if the link source and destination are both in Dropbox. This is not an EagleFiler-specific issue, though.
The symlink trick is normally used when you want to store the files (or some of the files) in Dropbox without storing the EagleFiler database and indexes there. If you want to store the whole library in Dropbox, you can just do that directly without any symlinks, with the caveat that you have to use EagleFiler’s folder structure.
There is no verification done when importing files.
Couldn’t you just move your original folder into the library’s files folder? That would avoid the copying, and I believe Dropbox is smart enough to not upload the files again.
This is something I’d like to add in a future version.
I don’t understand this comment. If the database is in Dropbox, it’ll be copied to each client unless you explicitly set Dropbox not to sync that folder.
You’re confirming my hunches
Yes, I did note that I could just move everything. There would be no duplication as there would only be one copy. And, yes, Dropbox is smart about moves and renames-it has its own GUIDs for file folders so it “knows” when the folders are the same as before, just with new names or in a new location. And, yes, as I acknowledged this would work.