I have several CS6 plug-ins whose zxps all install fine with Extension Manager CS6 on OS X 10.6 systems. However, on 10.7 systems, these same zxps are being expanded by EM such that what should be a symlink/alias inside the .InDesignPlugin bundle becomes a full copy of what the symlink is supposed to be referencing. In addition to other problems, this has the unfortunate effect of doubling the installed size of my plug-ins.
For example, ./Resources, which should be a symlink to the actual ./Versions/A/Resources folder within the bundle, is copied as an actual folder containing a copy of everything that's in the real ./Versions/A/Resources. Same with ./Versions/Current, which is supposed to be an alias for ./Versions/A but is instead installed by Extension Manager as a folder containing a full copy of what's in ./Versions/A.
I'm seeing this only in 10.7. Still happens using Extension Manager 220.127.116.11.
Extension Manager's Console Log entries look normal. In the "finishing deferred symbolic links:" section, log entries are emitted for each alias and no errors are being reported.
Has anyone else run into this? Any ideas? Thanks!
Chris Roueche / Em Software, Inc.
Thanks for the information, Carl. I'll 2nd Chris's motion that this be dealt with sooner rather than later. With Extension Manager creating corrupt bundles, we've had to ask our CS6/Mac customers to install their plug-ins manually.
Any idea what the timeframe for a fix might be? Thanks!
Yes, the other Chris will send you a pointer to our .zxp's that are proving problematic.
But this would seem to affect all Mac OS plugins under CS6/10.7, in that folders are being duplicated instead of symbolic links being honored. You should be able to see it with any plugin--they may not fail to work, but they'd be taking up a lot more space than they should.
We tested idcs6_Xtags.zxp with Extension Manager CS5.5 and CS6 on Mac10.7. The issue exists in both CS5.5 and CS6 on Mac10.7, although in some cases, it looks good in CS5.5. It is a known issue of Extension Manager on Mac10.7. We are evaluting the impact of this issue right now. Apart from doubling the installed size, is there any other bad effect which blocks you or your customers? Can your customers install/uninstall/enable/disable/use these symbol link extensions even if the symbol link was replaced by files? Thanks.
Hi Chris Ryland,
Thanks for the information you provided. We tested the extension CRoueche gave us. In some cases, Extension Manager CS5.5 has the same issue on Mac10.7 too. So it is a issue of Mac10.7. You said this particular bug would block your participation in the Adobe Exchange roll-out as your plugins fail to work in its presence. Could you explain it more precisely? Can you send us your extension just like CRoueche did( firstname.lastname@example.org )? Thanks.
As Harbs noted, Chris and I both work on the same team at Em Software, so we're talking about the same problem.
Chris can explain in more detail why this immediately breaks at least one of our plugins.
However, we believe it will eventually fail for ALL plugins on update, as Extension Manager won't find the appropriate resources. Try it yourself--install some plugins that seem to work on first installation, and then update them.
Some of Em's plug-ins use the InDesign SDK call IDBaseResourceShell::GetPathToPluginResourcesDirectory() to find pieces of themselves within the plug-in's bundle. For example, Em's DocsFlow plug-in uses this call to locate its "Versions/A/backflow" folder. Normally, this API returns "Versions/A/Resources", but in CS6/10.7 this InDesign API is returning "Resources", which causes DocsFlow to fail.
We can work around this particular limitation. However, this behavior hints that there's a more pervasive problem that may end up snagging every CS6 plug-in in 10.7. It shows that InDesign is finding and using resources and, potentially, a binary that are copies, copies that are not known by either the plug-in or Extension Manager (they're not in the .zxp's manifest). As Chris Ryland mentioned, when the plug-in is eventually updated, these copies of files run the risk of becoming stale... unless they happen to be replaced by the same 10.7 bug that put them there. And as you noted above, Xiaoyi, this 10.7 bug is flakey: sometimes it happens and sometimes it doesn't. So for updates to *always* work, consistently, Extension Manager would need to first remove the bundle before installing the updated bundle.
Hope that makes sense.
Of course, it'd probably be better if Extension Manager could work around the problem and install them properly to begin with. :-)
Thanks for continuing to look into this!
To add to what Chris said, I doubt if it's really a 10.7 bug--it'd be hard for them to have such an egregious error and have no one spot it to date.
It's more likely an interaction bug between the Flash/Air runtimes that Extension Manager is running on, and some change in 10.7 behavior.
Just a theory, of course.
There seems to be another aspect to this issue when trying to package an extension using Extension Manager CS6 on OS X 10.7. If the .mxi file refers to a Macintosh InDesign plug-in, the packaging fails with the error "Failed to package file '[...]/MyPlugIn.InDesignPlugin:Resources'. The extension package will not be created." So it's not seeing the symlinks as valid files when creating the package either.
This is also going to hold up Teacup from participating in the Adobe Exchange rollout, so from our perspective this is also an important bug.
Teacup Software, Inc.
Lawrence, that's good to know. I guess I should add that I'm building Em's CS6 zxps in an OS X 10.6 environment. So I haven't seen that particular failure yet.
The mix of POSIX and HFS-style separators in that error is interesting.
The root cause of packaging issue should be the same as the installing issue in that both cases need symbol link copying operation, which might fail on Mac 10.7. We are evalutating the impact of this problem and the effort to fix it. Thanks.
I think this issue affects any Extension Manager user under 10.7, as we noted above; it often fails when updating plugins, even under CS5/5.5, in our experience, symbolic links or no. (I just hadn't put the two facts together.)
So this is pretty critical, and apparently not a burning issue because so few developers use Extension Manager to distribute their plugins (partly because of its flakiness in the past, I'm sure).
So it may be past time to evaluate its impact and treat it as an emergency situation needing an immediate fix.
Thanks a lot for the information you provided. We are going to provide a patch for this issue, but it takes time( find a solution, fix it, verify it and deliver it ). We will let you know when the fix is available.
Once again, thank you for your patience.
Hi Chris, CRoueche and Lawrence,
Extension Manager CS 6.0.2 patch is available now. Please download( http://download.macromedia.com/pub/dw_exchange/extension_manager/mac/A dobeExtensionManager-6.0.2-mul-AdobeUpdate.dmg ) and install this patch to solve the symbolic link file issue in extension installation/packaging. Thanks a a lot for your patience!
Thanks--this seems to fix the problem we were seeing, at least from a simple test.
We'll let you know if we run into any further problems.
--Chris Ryland, Em Software
Great, looks like it works in Extension Manager.
However, it looks like this problem also exists in ucf.jar in the packaging and signing toolkit. Will it be fixed there as well? This affects how our plug-ins work on Adobe Exchange, since they need to be signed.
Yes, symbolic link files are not supported by ucf.jar, and we are developing a new package and signing tool for this issue. We will let you know when it is finished. Before that, you have to use a workaround --- replacing the symbolic link files with the files followed in your zxp file.
I'm not sure I understand the workaround you suggest. Are you suggesting going into the .zxp file produced by ucf.jar, unzipping it, and replacing all the resolved links (i.e. the duplicate files) with symbolic links? Besides being quite labor intensive, won't this invalidate the code esignature?
Hi Lawrence and CRoueche,
The workaround I mean is removing the symbolic link file in your content files, and replacing link file with the file it follows, and then packaging and signing by UCF.jar. For example, for content files like:
FileA( sym link file ) ------> FileB
You can change them to the files below.
FileA( a copy of FileB )
The new signing and packaging tool is in development phase. We will let you know when it is ready. Thanks a lot for your patience.
Is the new signing and packaging tool you're referring to "Adobe Exchange Packager"? If so, it seems to display the same problem of not honoring symbolic links, and it won't accept my signing certificate.
Additionally, I just tried the latest version of ucf.jar, with a creation date of October 3, 2012, and it displays a new issue. When I try to install an Extension created with that version of ucf.jar, Extension Manager displays the error "The extension 'com.[package name]' does not contain valid signature. The extension will not be installed." The identical files work fine with the ucf.jar version with a creation date of June 12, 2012.
Europe, Middle East and Africa