The manual for EF has the following caution:
• Google Drive is a Dropbox-like service. In our testing, it was slow, unreliable, and did not preserve file metadata. Thus, it is not recommended for use with EagleFiler.
But Google Drive is currently 10% of the annual cost of Dropbox. So, does anyone have recent experience with trying to use it?
Thanks for any comments, pro or con.
To clarify, Google’s Dropbox-like feature is called Google Drive. The EagleFiler manual mentions it here. I last tested it about two years ago.
Hey Roger – it’s a fundamentally different paradigm. With Dropbox, the file lives on your local drive in addition to being sync’d into the cloud. With Google Drive, there is a file on your local drive, but the only contents of those files are essentially https URL links to remote docs.google.com files, not the actual file contents. Thus while I’m sure EF could go through complicated machinations to download the file, do its thing, index it, etc… etc…, given that it’s such a different paradigm, there’d be a lot of things that would end up breaking.
In terms of alternatives, it will be interesting to see how Apple’s upcoming iCloud Drive pans out. Also, in some cases, you might see a lower price on Box.com… (e.g., http://it.dss.ucdavis.edu/news/box-com-available )
Speisert, thanks. I ended up going with Dropbox. We’ll see how well it works out.
I am looking forward to Apple’s new OS, although experience tells us it may be buggy for many months.
As far as Box, are you saying it uses the same paradigm as Dropbox?
thanks
Roger
I may not fully understand the original question and your response. I am new to EagleFiler. With that said, Google Drive does sync your local files. If they are actual Google doc, spreadsheet, presentation, type of files then like you said, they are essentially links to the contents stored on Google servers. However, any other types of file, a local copy is stored and synched with Google Drive and any other device you have connected/shared.
Like I said, I’m new to EagleFiler so I would not attempt to suggest that Google Drive is a good solution for EagleFiler (yet). I’ve found Google Drive to work very well in synching files of many types. No significant problems or complaints here. I’ve also synched somewhat complex file systems, e.g., DEVONThink “databases”, across several computers too.
I’ll be testing EagleFiler with Google Drive. I suspect that any meta data that may be lost is a hidden file. I’ve not experienced any meta data loss from document type files, e.g., pdf, doc, ods, etc., on Google Drive before.
Thanks,
Charlie
Hi Roger,
Yes, Box.com uses the same paradigm as Dropbox. By the way, more reviews here:
Cheers,
Sean
reviving thread
Wow, would it be nice if Google Drive worked with Eaglefiler. I spend $100 a year on Dropbox; that’s on top of the $100+ for Office (OneDrive doesn’t work well with Eaglefiler, either–a file-name-length problem; otherwise I could just use that service).
Plus my office now uses Google Drive, so I’ve got stuff spread across three cloud services. (Dropbox for most of my “home/freelance” stuff, OneDrive for OneNote (which I live in, in my office), and Google Drive for my day-job.
I tested Google Drive again. The performance problems of the early versions seem to be fixed. It still does not preserve creation dates, file labels, or extended attributes. If you don’t mind losing those, you should be able to use it with EagleFiler.
Hmm. Creation dates are certainly useful. From the above reference to Box using the same “paradigm” as Dropbox, I take it Box and Eaglefiler work well together?
[Add/edit: I just read the manual and it sounds as though Dropbox doesn’t save creation dates either, so I guess I haven’t been using them to begin with! So $24/year for Google may be the way to go, for me. It would be $60 for Box, and I pay $100 for DropBox.]
Of the services I tested, I think iCloud Drive is the only one that supports creation dates. Overall, I think Dropbox has the best metadata support.
What are the “extended attributes” that get dropped by Box and some of the others? (I always feel bad that it’s Michael who answers questions like these; he’s busy enough. Does anyone else know?)
For most modern apps, there is probably nothing essential in the extended attributes. It really depends on the apps that you use. Some apps use them to remember user state about the file, e.g. its text encoding or cursor location. The system uses extended attributes to store file tags. However, EagleFiler has its own tag storage and can restore the tags if the extended attributes are lost. The system also uses them to store extended permissions information if you are using ACLs.
Older Mac files sometimes stored important data in the resource fork, which is stripped by the services that don’t support extended attributes.