Readers of this blog are aware of the issues in Version Cue CS4. It was an unmitigated disaster due to its network drive architecture. The lure of a transparent version control system is hard to resist.

It appears Adobe has decided to resurrect the Adobe CS4 drive technology in the form of Adobe Drive 3. In this blog post we look at why this is a bad idea and what are the alternatives.

First of all a little bit of background about Adobe Drive 3 architecture is warranted. It may get a bit technical but I will try to keep it simple for our creatives who are the primary target of Version Cue and its alternatives.

What is Adobe Drive

Its a file system overlay technology to allow you to mount a remote repository as a drive (Windows) or a mount point (Mac) on your desktop. Once mapped, you can use Finder or Explorer to browse the repository as if it was a network share. In other words the abstraction of  a drive or a remote volume hides the details of a Digital Asset management (DAM) store from the end user. In theory may sound like a great idea but in practice may be not.

For instance in the screenshot below you can see Z: maps to a remote Adobe Drive based asset store:

Adobe Drive 3

So, then what’s wrong with this? Here are my top 8 reasons why it sucks -

1. Fundamental scalability issue: One of the Adobe Drive 3 provider had to say this on their web-site:
   

   Adobe Drive 3 5000 file limit

   I don’t know about you, but in our workflow we can easily generate thousands of Cinema4D image sequences with multiple passes  that are then consumed by Photoshop or After Effects. We have a stock photo folder with over 30,000 images. When I hear stuff like this, its CS4 Drive deja vu  all over again.

2. On my MacOS X, according to Apple I can have 2+ Billion files on a folder: http://support.apple.com/kb/ht2422 . I don’t want to go near anything that smells like a toy app but will not scale for large data volume.
3. Adobe Drive 3 works with certain Adobe products. If CINEMA 4D or Autodesk products tried to open remote files they will get errors (see Opening a remote file http://help.adobe.com/en_US/creativesuite/cs/adobedrive/Adobe_Drive_3_User_Guide.pdf ) . This is documented in Adobe Drive 3 user guide.  Drive 3 is really meant for only 3 Adobe CS applications: Photoshop, AI, InDesign. That’s too limited for a creative group I work with, we do use CS a lot but there are so many other tools we work with that I can’t even begin to imagine using a solution optimized for a subset of the tools I use.
4. Slow as hell: File browsing will require constant network activity  as the requests for file attributes will require sending XML/SOAP request or a vendor specific remote call.We have teams that span multiple buildings and cities and continents. Our CIFS/SMB network share sucks, are you telling me a non-storage vendor can write a better file system driver than Microsoft or Apple? It gets worse with Adobe Drive 3. First Adobe has to ensure their overlay file system driver functions fast enough and then the DAM vendor’s plug-in into Adobe Drive 3 has to ensure it does not screw up file integrity by generating exceptions or errors while files are being written or being read.When I tried to write an AutoCAD file to Adobe Drive, I got a strange Windows OS error about invalid set attribute call!  Most implementations of Adobe Drive 3 use a base64 encoding to send/receive content. Base64 encoding adds 33% overhead to whatever content is transmitted.  This is not a conjecture but basic science behind file encoding (see http://en.wikipedia.org/wiki/Base64).  A 100GB asset will need ~ 134GB to transmit when using Adobe Drive 3. That is just the network overhead.
5. No file or folder coloring or overlay icons to visually tell me which files are checked out or locked, no support for advanced versioning features like tree merges, structure conflict resolution, changesets, change logs, deduplication.
6. Not being able to use all my drives: In our workflow, we often have data on multiple network shares or multiple volumes mounted from our NAS or SAN storage devices.  Depending upon the size of the asset I may want to copy or cache it on different locally mounted drives. With Adobe Drive 3 it allows only one cache folder:
   

   Single cache folder in Adobe Drive 3

   We need the ability to use muliple folders based on asset sizes, for example large videos will reside on a bigger SAN volume, while smaller documents we may put them on a Direct Attached Storage (DAS) local drive. Caching policy is totally controlled by Adobe Drive 3, this is unacceptable as many a times we will checkout a large document/file and may not modify it but reference it in our project. To have it removed from cache and re-fetched slows down the workflow. Again this may be ok for smaller files or creative projects which don’t need large files like ours do.

7. Given the history with Adobe Version Cue CS4 Drive or Adobe Drive 2, what assurance do we have from Adobe that architecturally this is a better idea? I would think a lot of Adobe Version Cue CS4 or Drive 2 code must have gone into Drive 3?
8. Who supports Adobe Drive 3? If we buy a DAM solution that plugs into Adobe Drive 3 and if history is any guide, like Version Cue CS4 there will invariably be bugs with Adobe Drive 3. See known issues at - http://forums.adobe.com/community/creativesuites/adobe_drive
   

   Connect problem with Adobe Drive 3

   

   corruption issue in Adobe Drive 3

   If an issue arises with an Adobe Drive 3 connector it could be 1) Adobe’s bug 2) Vendor who provided the connector may have a bug. Given how unresponsive Adobe was with CS4 issues, here there is even less incentive for Adobe to support unless you are using their expensive CQ5 DAM. I don’t want to be ping pong ball between Adobe and Drive connector vendor.

    

I would stay away from Drive based technology if I were you, once bitten twice shy. In a future post we will look at alternatives to Drive based approach.