EF vs DEVONthink Pro

[ginopiazza49]

Seeing how there is a thread titled "EF vs Yojimbo?", I thought that I would start a thread titled "EF vs DEVONthink Pro." I am currently using DEVONthink Pro. In the meantime, I am trying the EagleFiler demo. I like the idea that EF keeps your files intact.

I would like to hear from others why, other than the reason I mentioned, I should go with EF rather than DTP. Or should I stick with DTP? Go ahead and convince me one way or another.

[crux]

tags.

[macsterdam]

It all depends on your needs. I currently use DTP, but have bought and am testing EF, because it has several things I like. This is what I find, in order of importance:

pro EF
tags
spotlight integration
files in one place
files take up less space (my DT database is 360 mb, EF only 70 mb)
droppad
feedback when capturing


pro DTP
faster
smarter
keywords
full-screen mode
replicate
more scripts
history

[hinnerk]

What I really like about EagleFiler is...

• Open File storage. I do use Linux, Solaris, OpenVMS and sometimes even Windows. Being able to access a EF Archive on a FAT formatted USB Stick is really great.
• Archive/file verification for FAT on USB is a must, because of USB protocol deficits.
• It's really easy to get a list of filename and md5 to verify a archive with md5deep on Unix.
• Without ECC RAM archive verification is a must. I don't know any Apple desktop machine capable of using ECC RAM.
• Maybe dito for IDE storage or some file systems (has anyone ever seen bit rot of unmodified files?).
• A few days ago a large import caused EF (Version 1.1) to hang. Rebuilding the index took away the problem but not the metadata.
• RO archive of mail is just great! (It's easy to modify anyway, using a mbox capable mail client like mutt.)

Hmm, all in all it seems I'm going to buy EF if my big archive import works today.

[Michael Tsai]

It's really easy to get a list of filename and md5 to verify a archive with md5deep on Unix.

Just out of curiosity, why are you using "md5" yourself, when EagleFiler's Verify command can do that for you?

has anyone ever seen bit rot of unmodified files?

Yes, several times; this was one of my motivators.

RO archive of mail is just great! (It's easy to modify anyway, using a mbox capable mail client like mutt.)

Just to be clear, it's not a good idea to edit mbox files in place (unless you don't change the file length or any message boundaries), since this will mess up EagleFiler's table of contents file, which keeps track of where each message is located in the mbox.

[hinnerk]

Just out of curiosity, why are you using "md5" yourself, when EagleFiler's Verify command can do that for you?

Two reasons: Backup verifying and peace of mind while travelling light (with USB Stick and Linux/Solaris/Windows people around).

When I use multimedia oriented storage (DVD,CD) I usually print the md5 or sha1 of the archive files on the cover. Sometimes I'll print it even on MO Cartridges, because of those who connect MO drives via USB.

Only backups with hash verification are good backups :-)

Yes, several times; this was one of my motivators.

Up to now I was always able to blame it to bad ram or USB (always reproducible). If it is not too much time and efford for you I'd be glad to hear more about your "motivating moments".

Just to be clear, it's not a good idea to edit mbox files in place (unless you don't change the file length or any message boundaries), since this will mess up EagleFiler's table of contents file, which keeps track of where each message is located in the mbox.

Oh, sorry, I should have been more clear on this. Of course I always make a copy of the mbox file, delete it in FE, modify the copy with mutt and import the modified copy into FE.

[brab]

Just to be clear, it's not a good idea to edit mbox files in place (unless you don't change the file length or any message boundaries), since this will mess up EagleFiler's table of contents file, which keeps track of where each message is located in the mbox.

I guess this calls for a feature request: an option to reimport a record. (Automatic reimport upon modification would be great, but detecting modification might involve hashing the file, which could be big in the case of mailboxes...)

[j-tummins]

I currently use DEVONthink, but I'm actively looking for a replacement. EagleFiler is the leading contender.

My evaluation of the relative strengths, in order of importance to me:

pro EagleFiler

• Integration with the Finder - transparent library
• rapid response and support of the developer
• tags
• Mail archive handling
• multiple libraries opened simultaneously

pro DEVONthink

• speed
• "see also" and "auto classifiy"
• index external media (such as the contents of CDs and DVDs)
• replicants
• web site export of selected folders

Some improvements that I'd like to see in EagleFiler would be:

• convert .rtf to .rtfd automatically (such as inserting an image into a document)
• improved speed
• "see also" and "auto classify"
• indexing of external media

[j-tummins]

How could I miss these?

pro EagleFiler

• arbitrary file types (Excel, OmniOutliner at least. This is a huge advantage.)

pro DEVONthink Pro

• auto grouping

Auto grouping is the ability to create a new group with contents resulting from a search.

Smart folders would be a big plus. Devon Technogolies has been promising this for some time. They just never seem to materialize.

[crux]

I think all the auto-grouping/classifying/see-also features would be out of place in EF. I used DEVONthink for quite some time, and never really found them useful -- and that was in an app devoted to that AI system! I think that to try to replicate the functionality in EF, or to replicate the content-parsing system, would be barking up the wrong tree.

[sjk]

I semi-reluctantly agree with you, crux.

The idea of a single app that eventually subsumes what I like best and use most in DEVONthink/EagleFiler/Yojimbo/<…> can be personally (selfishly?) appealing. I'm guessing a few people feel similarly or this thread probably wouldn't exist. :-)

The current reality is that these apps exist separately, with distinctive strengths and features to make them uniquely advantageous for different people and purposes. Of course they already have many things in common and undoubtedly will share more in the future. Perhaps a feature or two in one may be enough for some people to be satisfied using just one. And hopefully interoperability improves for anyone using more than one; that issue could easily be discussed as its own topic.