No change. Opened InCopy CS5 document in InCopy CS6, saved as a new document. Chose Relink in InDesign document. Same crash-inducing, serious error. (The InCopy document, by the way, is simply text with a few paragraph styles — I won't get into InCopy documents with graphic anchors, etc.)

Creating a new InCopy CS6 document, copying content from existing InCopy CS5 document and pasting content into new document also produces same crash as does attempting to place this (or previous iterations) in a new InDesign CS6 document.

But, placing InCopy CS5 or InCopyCS6 document in a new InDesign CS5 document (running both versions concurrently) is successful.

No, I use FontCase by Bohemian Coding. Currently I have its auto-activation feature disabled. Which, by the way, I have found to be very unintrusive as a Mac font management application.

AM, this is Rocio... yes THAT Rocio... experiencing this very frustrating problem with the ID/IC workflow that used to work so well until a few weeks ago.

So, here I am now asking if the combination you suggest is the 'winning combination'... did you got to know the answer to your question? If so, I would like to know how that worked. :-)

JA Flint, thanks for the information! :-)

You have saved me lots of running around in circles!  I am passing this information to my IT people and we will be looking to have the version combination you are suggesting and see how it goes.  At the same time, I will keep an eye on the other ID/IC workflows in our department to check how are they working with their own software versions. Now, I am curious to know which versions are they working with.

Later on, I will report on the results from implementing from your advice to assist other possible users looking for a solution to this issue. Also, as you mentioned, hopefully Adobe will fix this issue so that we can move forward with new software versions. At this time, if IC 7.5.3 and ID 7.5.2 work well and the issue is fixed, we will probably not be installing newer software until the issue is fixed at the software level with no need of work-arounds.

Thanks again! :-)

We are also having major problems with our InDesign/InCopy layout and assignment workflows in Win 7, have contacted IT support and still no help going forward.

The recent upgrade to both InDesign and InCopy CS6 (both have the latest patches installed) has not helped, our workflow uses both shared network and dropbox, neither seem stable.

We have posted similar Proectiveshutdown logs,  see below

Adobe InDesign Protective Shutdown Log

02/04/13 10:40:22

Unhandled error condition

Session started up at 10:39 AM on Monday, February 04, 2013

Version: 8.0.1 - Build: 406

Error Code 0x20705: "The content is locked and cannot be modified."

Called to process command 0x7313

Command Processor Stack (from top to bottom):

8. Command Sequence "Re-import File"

7. Command 0x7314 "Re-import File"

6. Command Sequence "Update"

5. Command Sequence ""

4. Command 0x8c59 "Update Link"

3. Command 0x18e38 "Relink Story"

2. Command Sequence "Relink Story"

1. Command Sequence "Update Story"

--------------

The problem always seems to be the same after a simple editorial change to the .icml files.

Adobe need to sit up and pay attention to the problems we have been experiencing.

I still experience issues with this as well, and I think I was one of the original posters. I thought I would take a second to "bump" my experience and crude fix in the forum.

For me it seems to be a problem with InDesign gathering hyperlink destinations. InDesign will include these URLs, appending them to InCopy files that are getting edited and checked-in in InDesign. From there something happens where a URL can start duplicating, many hundreds of times during subsequent check-out/check-ins.

I sometime examine the InDesign document's destination options deleting the unnecessary ones.

More importantly, I now use Apple OS X Smart Folders in the Finder to monitor production folders for .icml files over 500KB (for my purposes — magazine articles — basic InCopy files that are just text in nature are typically well below 300KB).

If I see an InCopy file is behaving badly (bloating in size unexpectedly) I will open it in a simple text editor and remove the excessive Hyperlink Destination XML elements and save those changes to the XML. This generally fixed the problem.

I hope this makes sense, and might be of use. I realize the previous poster's comments might be more about chiding Adobe for not fixing the issue than looking for someone to chime in with their observations.

I believe I may have some insight to share on this problem.

I produce a magazine in InDesign CS6, and the editors use Incopy over a shared dropbox account.

As we start creating articles, I usually export them to Incopy one by one, just the text frames that I expect them to edit. However, at some point in production, it becomes necessary to unlink all of the Incopy stories, delete those links, and then create clean links - usually because another designer wants to be able to copy text boxes and move all the pages around and having everying linked in Incopy makes that more cumbersome.

When it's time to remake the Incopy links, I have several times tried using "Export all stories" to create them all at once. DON'T DO THIS. I believe this is one of the main causes of the problem because there are various pieces of text that you don't want linked via Incopy - such as master page footers, section markers, anchored text elements, text labels on a digram that are in small round text boxes, and so on. I think these are the things that cause the crashing when you try to update an Incopy link - even if the one you're updating has none of these features.

So, instead, after a clean sweep of all linked text, I now re-export the Incopy links manually. I go one spread at a time, and highlight all of the relevant text frames at once, and export to Incopy. That way I know I'm only exporting the frames that have the main text in them that will be edited, and not the "decorative" text or locked items.

This may be prohibitevely time-consuming in some projects, but until Adobe is able to fix the application, I believe it's one way to solve the problem. Seems to help on my magazine.