Hi, I'm debugging an Adobe Drive CC connector and seeking advice on the following problem:
After I check-in an Illustrator file, the local copy becomes corrupt.
If I make a change and try to save it, I receive a message stating "The file is damaged and could not be repaired." If I close the file instead, I can't re-open it (same error message).
However, if I Empty Cache in the Adobe Drive Settings that fixes everything and I'm able to open/save the file without any error. (When I check it in, the same problem repeats itself until I empty cache again).
Where does this message come from and what conditions can trigger it? It's difficult to debug without Adobe's sourcecode to step through the event, but I wonder if it has to do with Etag data?
I've confirmed the stream data downloaded by the open & read handlers is not actually corrupt (by setting a breakpoint after the tempfile is written and checking it's md5).
The problem occurs after every checkin of Illustrator files, but never with Photoshop files.
Any advice? Thanks
I wish I had an answer, but I at least wanted to post in solidaridity and bump this thread. I've been experimenting with Adobe Drive CC (220.127.116.11) and am also suffering from the "file is damaged" issue.
I am using the CMIS connector and after almost every check in or out the file becomes corrupt -- but only in the Drive cache. If I clear the Adobe Drive cache the file is perfectly fine. I have watched the CMIS traffic in Wireshark and it appears to me that this error is entirely within Drive: it does not get a new copy of the file that's corrupted en route, it just corrupts its own copy in the cache.
I experience this with all file types.
Out of frustration I tried Alfresco 4.2.e, which is supposedly the software Adobe worked with to "polish" the CMIS connector, and the problem is entirely different. Every check in failes with "The operation could no be completed because of an unexpected error. Error Code: -1" and a RemoteIOException in the Drive log.
Drive then announces the file "has changed since I opened it, and it will be updated to the newest version" -- which DOES bring new bytes over the wire and avoids the corrupted local cache. Is that somehow the answer the Alfresco has discovered, to break the transaction and force Drive to refresh the file?
Please, anyone, chime in you've experienced either of these issues. I have yet to see a successful use case for Adobe Drive over CMIS, but surely someone is using this product?
Following up after burning a lot of time on this, hoping this is useful to the next person:
OP, can you check for something similar?
It's an option in the DAMS, you can either store XMP in the data fork or the resource, and leaving it out of the data fork apparently keeps Drive happy by keeping the file size in sync. Weird. I feel like both our solutions are hacks, but for now it's working so...