We have a brand new look! Take a tour with us and explore the latest updates on Adobe Support Community.
I created a publication based on a previous one. It's in a new folder with the default [fonts] and [lins] subfolders. Preflight shows no linking errors. Since there are numerous unused graphics in the link folder (from the old version), I wish to create a new package before sending to production. I get the above error with no explanation. How do I do this without manually copying every link (70) and font (46)?
This is CS3 on Vista Home Premium.
Do you have enough room and permissions to save the files to the new folder?
One workaround. Select all the links in the links panel and from the panel menu choose copy links to and select a new location.
No issue with space or permissions. In fact, I just packaged another publication with no issues. Your work-around is great, didn't know that was there.
I am having the same issue as larrycfc above. I thought what a great work around I copied the links, but it failed. Any other ideas? I am now going to look through all the names of the pictures linked to the publication. Updating the software did not help.
Ok, I took the time to look at every link and there was one with a / in the name and removing that fixed the problem. I also removed all the ( ) and % characters to be safe. This forum has saved me, yet again.
@hfaulconer – the real problem here is, that one part of InDesign can handle these file names, the other part can not. The Place module and the Links Panel (showing the files) obviously can, the packaging or the copy/move functionality can not.
Did the naming problem lie in your file names or does it lie in the names of the new introduced folder structure (the folder names)? Did the problem occur because you wanted to redirect the links to a folder named with "special" characters?
In Mac OSX file names with "special" characters like "(", ")" and "%", but also "/" are allowed. These are the basic rules of OSX for more than ten years now. Adobe is not supporting OSX enough, I think…
That does not mean I want to encourage the use of these "special" characters.
When leaving OSX (transferring files), I'm well aware, that naming files to its full extend would be a big problem.
While I'm a bit late to the gig, I'd like to throw in another view on this in case anyone else stumbles across this thread as I did.
Beyond characters, don't overlook character count. If you have corrected any strange characters within your filename and your packaging or link copies still fail, then maybe take a look at the length of your filenames. I've run into this a few times where technical illustrators will name their artwork files with really long exacting names of what the illustration is. Once placed within a network working file structure, InD/Artwork/Chapter, or whatever, you may simply have just reached your character limit. We've run into that from time to time, but mostly at the DVD burn level. This is the first time that I've experienced it with packaging straight from InD.
My experience just this morning brought me here to this forum thread. Thanks for the references and help so far everyone! I did find a () in one of the artwork file names and updated it. Upon relink and package, I still received the same error as the OP. I tried the copy to... option from the Links panel with a similar error. Well, I decided to manually copy everything over through Windows Explorer and finally received a more detailed error noting file name length. Voila (at least for me).
I found the longest named file and renamed it. to test (don't forget to relink!!), I ran another InD package and this time it worked.
So, I will be having a discussion with my artists later today to stress file naming LENGTHS lol. One step at a time.....
Thanks all who have posted suggestions and solutions. it is much appreciated.
Then What is the advantage of packaging. ?
And In link panel i could not find any option to copy all links into one location.
You just responded to a 6 year old post. I'm locking this discussion.
If you need help start a new one with full details.
You were moving the new package to a new folder, yes? I can see where there would be some issues in the same folder.
Yes, new folder.
I had a image file with a forward slash ("/") in the name that was causing the issue for me.
This thread is two years old and AFAIK this issue was fixed with a patch to InDesign. Make sure you're fully updated by checking under help>updates.
One of my students was having the exact same problem with CS5.5 !!! The problem still exists and I suspect that it was as rivet proposed in the previous post. My student was using serial naming 1), 2) and I suspect that it was the parentheses that were generating the issue. I changed one GIF file from indexed colour to greyscale and renamed it without the bracket from 13) maid.gif to "13_maid.jpg" and this allowed the PACKAGING to proceed but it crashed InDesign before generating a copy of the original layout and the instructions file. It did manage to copy the fonts and links. However, on trying it a second time I got the dreaded "Cannot copy necessary linked file(s) error message.
I am going to get her to rename and re-link her files to see if this resolves the issue.
Sorry but I just ended up here because I had the same issue (creative cloud), so I guess is not fixed like you said. For me it was a slash on one of the links titles.
I just had this issue for the first time, and I found this thread. Once I saw the possibility of a filename with a forward slash, I scanned through my linked files and found the needle in a haystack. I renamed the file to remove the slash. Then I relinked the file and was able to package the file successfully. Problem solved. Thank you rivet!
Hi all just have the issuu... an images file hade 15/16 I made it 15-16 and the no problem.
Hope it helps
This solved it for me too.
Issue is definitely still there in CS6. Renaming any links that had forward slash ("/") in the name did the trick (as per other comments above).
Pity my client has a naming and code system that uses a forward slash and will be impossible for me to change to avoid future issues.
If your clinet intends to do any work in a modern networked environment they're going to need to learn not to use slashes in file names.
That's the attitude. Adapt to the limitations of the way that the networked environmnet has been built and operate - rather than aim to improve and become flexible enough to work with characters and glyphs that have been used in communication for thousands of years.
I think i'll stick to complaining until things get easier to work with.
Hey, that's just reality.
Computers are not as smart as you are, so they need rules to follow. People around the world on diverse operating systems have agreed that certain characters will be used to mean very specific things in the networked environment. What you are asking is akin to saying joeshmoe&somedomain!com will be considered a valid email address.
Peter - while I completely agree with you that bad filenaming conventions should be avoided, I think it's irresponsible to rule out acquiring files that someone else named poorly. Unfortunately, most of the problems I encounter with bad file names is related to a client or designer that sent us poorly named files.
I guess what I'd like to see from the Adobe community and InDesign team isn't a lecture on bad file naming, but a solution to the root problem. Perhaps a feature in the links palette akin to the "relink with a different extension" that utilizes regular expression or string substitutions for filenames. For example, I receive a file named like this:
If I rename the files with Bridge's spectacular batch rename with string substitution to remove these bad characters, couldn't the links palette in InDesign utilize the same code in some way to find the same bad character patterns to something like below?
Thus, removing the periods that aren't at the end of the file where the extension is, swapping all bad characters to underscores, and removing the double file extension to the preferred one?
The problem that brought me to this forum post is that I had files with double extensions. InDesign only reads the final period followed by extension. Anything before that period is considered part of the filename. When working on a document with hundreds of links that were acquired from a previous publisher's files, it's frustrating that one piece of Adobe software has the smarts to fix the filenames, but InDesign has no way of finding them automatically.
It just seems like the parts are there, and somebody just needs to make it all work. I may be oversimplifying some serious coding, but that would be a feature that would bring a smile to my face, and solve a lot of the headaches that bring people to this post.
Every tool has its functions. InDesign is not intended to edit file names anymore than it is to edit photographs.
If you got files with bad name, rename them or charge the client for failing to adhere to specifications. To expect the InDesign team to spend all kinds of resources to add functionality that already exists in Bridge is not something I would hold my breath waiting for.