I have asked this earlier, but the question got downwoted and deleted by any reason. The original is here:
https://stackoverflow.com/questions/47749448/filemaker-14-runtime-high-sierra-download-versus-copy-from-server
I am posting it again since I now have found the solution that is highly relevant for others having the same issue.
Original question:FileMaker 14 Runtime / High Sierra / Download versus copy from Server
Our solution consisting of a couple of FileMaker files built with runtime option. FileMaker14
When packed as a ZIP archive, or a DMG package - The result depends on how the package is downloaded.
Option 1: Distributed as a download link. When unpacking, the application does not work as expected. FileMaker ask for missing files in solution.
Option 2: Same file put on a FTP area, and connected as a remote disk. Then dragged into the the computer. Unpacking, all works well.
Does anyone have a clue what is going on here ?
I have found what is causing this.
Apple has introduced something called "Gateway Path Randomization". This is basically that the App-file is moved by the gatekeeper to a random location prohibiting it from accessing the database files (That is relative to the app itself). This occurs when an app is downloaded from the internet, and not have any certs. To Solve this, You need to sign the DMG archive with a propper certificate. I used DropDMG to accomplish this, then the translocation process does not occur when user is launching the app.
References:
https://community.filemaker.com/thread/165583
https://mjtsai.com/blog/2016/06/16/gatekeeper-path-randomization/
Related
I use AnyLogic PLE v8.76 on mac. It worked fine for a week, but today I got problem launching the software. I keep getting this message:
And this is the error shown:
I tried to download Anylogic again, but I still got the same problem...
I did not download any other softwares or change things on my mac.
Can somebody help me?
Thank you!
Best option, as often advised by the AnyLogic support team, is to clear the workspace.
Try the following:
Make hidden files and folders visible on your Mac - cmd+shit+.
Navigate to your user folder (Either from he side bar, or Macintosh HD -> Users->(yourname)
Find the .AnyLogic... folder, on mine it is called .AnyLogicProffesional
Delete the following two folders workspace8.x and configuiration8.x where the 8.x indicates your version number of the currently installed AnyLogic version.
These files keep settings and the currently loaded models on the disk and will remain even if you download a new version of AnyLogic, which is why downloading a new version does not always solve these kinds of problems.
If the issue still persists contact support, they might ask you to send the error report you got from your Mac (so copy and paste it to a document the next time you get it) as well as some error logs that get stored in these hidden files and folders. (Now you at least know where to find them ;-) )
If my solution did not provide the answer, please add an answer if you manage to find it.
This issue has been discussed several times on Stackoverfl0w, but unfortunately I did not see any really satisfying solution.
The situation:
(Only included because most previous answers went with the line of "Just dont do it! There is no reason to have multiple version of an application.. etc.", which I agree with for most cases, but not this one.)
We are currently shipping a .pkg file that installs our software package to /Applications/$CompanyName/$SoftwareName_$VersionNumber .
Including the Version number in the folder's name and not deleting older versions is necessary since many of our customers use our current release and beta version in parallel, and, furthermore, many customers work with an older version software because they certified it for a specific use case, but they use a current version for current projects.
We used to ship only command line tools and libraries for macOS, therefore it worked totally fine for us over many years.
However, we started porting our GUI applications from Windows only to Windows / macOS / Linux, which are shipped in the .app format under macOS.
The issue:
If an .app is shipped within a .pkg installer, the installer searches the hole disk for old instances of the same .app .
If it finds one, it replaces the instance it found (very bad) and also does not place the .app in the specified installation dir (also bad).
Solutions I found:
a) Changing the CFBundleIdentifier of the .app for every released version. Seems not like a clean way to me. I assume it will also cause the .app to appear multiple times in the Launchpad
b) Searching all instances of the .app before the installer does it, zipping them, and extracting them again after the installation. (Also does not sound like a good solution.)
Does someone have a clean way for this?
Can not believe that Apple does not have a way of specifying that this behavior should be omitted during the creating of the .pkg.
Is there better documentation then the one I found?:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.html#//apple_ref/doc/uid/TP40005370-CH100-SW15
http://s.sudre.free.fr/Stuff/Ivanhoe/FLAT.html (Good documentation, but after ~8 years of uptime, a lot of the fields are still labeled with "Description Forthcoming.")
EDIT:
Added XCode as a Tag.
Bumping after earning the tumbleweed with this question.
Would appreciate any suggestion :)
The "relocate" property in the distribution file seems to control this. Unfortunately, it appears you can only enable "relocation" by adding this key, but not disable it by omitting the key. According to Apple's Distribution XML documentation, the default for .app bundles is "relocate".
I am in an interesting situation where I maintain the code for a program that is used and distributed primarily by our sister company. We are ready to distribute the program to all of the 3rd party users and since it is technically our sister companies program, we want to host it on their website. (in the interest of anonimity, I'll use 'program' everywhere instead of the actual application name, and 'www.SisterCompany.com' instead of their actual URL.)
So I get everything ready to go, setup the Publish setting to check for updates at program start, the minimum required version, and I set the Insallation Folder URL and Update Location to "http://www.SisterCompany.com/apps/program/", with the actual Publishing Folder Location as "C:\LocalProjects\Program\Publish\". Everything else is pretty standard.
After publish, I confirm that everything installs and works correctly when running directly from the publish location on my C: drive. So I put everything on our FTP server, and the guy at our sister company pulls it down and places everything in the '/apps/program/' directory on their webserver.
This is where it goes bad. When I try to install it from their site, I get the - File, Program.exe.config, has a different computed hash than specified in manifest. Error. I tested it a bit, and I even get that error trying to install from any network location on our network other than my local C: drive.
After doing the initial publish in visual studio, I have changed no files (which is the answer/reason I've found by doing some searching about this error).
What could be causing this? Is it because I set the Installation Folder URL to a location that it isn't initially published too?
Let me know if any additional info is needed.
Thanks.
After bashing my head against this all weekend, I have finally found the answer. After unsigning the project and removing the hash on the offending file (an xml file), I got the program to install, but it was giving me 'Windows Side by Side' Errors. I drilled down into the App Cache were the file was, and instead of a config .xml file, it was one of the HTML files from the website the clickonce installer was hosted on. Turns out that the web server didn't seem to like serving up an .XML (or .mdb it turns out) file.
This MSDN article ended up giving me the final solution:
I had to make sure that the 'Use ".deploy" file extension' was selected so that the web server wouldn't mangle files with extensions it didn't like.
I couldn't figure out why that one file's hash would be different. Turns out it wasn't even the same file at all.
It is possible that one of the FTP transfers is happening in text mode, rather than binary?
For me the problem was that .config transformations were done after generating manifest.
To anyone else who's still having trouble, five years later:
The first problem was configuring the MIME type, which on nginx (/etc/nginx/mime.types) should look like this:
application/x-ms-manifest application
See Click Once Server and Client Configuration.
The weirder problem to me was that I was using git to handle the push to the server, i.e.
git remote add live ssh://user#mybox/path/to/publish
git commit -am "committing...";git push live master
Works great for most things, but it was probably being registered as a "change," which prevented the app from installing locally. Once I started using scp instead:
scp -r * user#mybox/path/to/dir/
It worked without a hitch.
It is unfortunate that there is not a lot of helpful information out there about this.
A client's Magento site had weird characters in the top of Magento Connect:
We tried installing a plugin and got the following error:
It turns out the problem was a bunch of (hidden) duplicate PHP files in lib/Mage/Connect. For example, there's Remote.php but there was also ._Remote.php. This forum post was how we found out the details.
(Deleting the duplicate files corrected the problem).
I'm wondering -- has anyone else experienced this duplicate PHP file problem in Magento before? Any idea what the cause is?
These files are mostly likely meta-data files for OS X's HFS+ file system. See this entire thread on the Apple Stack Exchange for some good starting points if you're interested in the details.
Oversimplifying things, when you create a tar archive on OS X these files are included along with the "real" file. This allows Macintosh specific meta data to survive the trip into a file format that wasn't created specifically for the Mac. If you untar the files on a Mac, the meta-data is preserved. If you untar the files on a non-Mac, the ._ files are generated in case the meta data is needed.
My guess is, at some point someone tared up those files to move them to the production server from their Mac, which brought along the the ._ files for the ride. You can avoide this in the future by running
export COPYFILE_DISABLE=true
from the terminal prior to copying the files. Details on this here.
(It's pretty bizarre that PHP would attempt to include those files instead of the correct files — did you debug this far enough to know why/what connect through it was doing?)
For one of my clients, I've developed a small iOS app. I'm a member of their dev team, so I've been using a development certificate to sign my local test builds.
Now the app is almost done and it should go into internal testing on the clients side. I created an archived build of the app which I then sent to my client. They imported it into the organizer and tried to "Share" it to be able to re-sign it using an ad hoc profile.
Creating the .ipa fails with an "no such file or directory" error though. The archive appears to be fine otherwise - the organizer shows all the usual information, the icon, and it will let them export it as another archive. Creating an .ipa without re-signing fails as well, which leads me to believe this is not an issue with ther certs and provisioning profile.
If I try the same thing on my side, writing an .ipa from the very same archive using my development cert, the operation succeeds.
It may be worth mentioning that the same procedure was working fine while we were still using XCode 3.x on earlier projects. This is the first time we've been trying this using XCode 4.
No additional (static) libraries have been used.
Any help greatly appreciated!!
Edit:
Someone at the apple dev forums suggested to me that I should check the system console for xcode error messages while attempting to export the .ipa - none were printed out. We discovered some other, older messages however, which read as follows:
18.04.11 13:54:35 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode[123] /Users/User/Library/Developer/Xcode/Archives/2011-04-15/Foobar.xcarchive/dSYMs/Foobar.app.dSYM/Contents/Info.plist:
set flags (was: 00200000): Operation
not permitted
The timestamp is roughly at the time when my client first imported my archive, but we can't be sure since we didn't watch the console back then.
The message had been printed multiple time, once for every single ressource file contained in the bundle. Does this tell you guys something?
Problem solved.
Following another suggestion on the apple dev forum, we repaired permissions on both systems. Additionally, I built and archived the app again and used a different way to transmit the archive to my client. We did all of this in one try, so I can't quite tell which of these measures actually did the trick. If you stumble across this because you have the same problem, you might want to try all of this, too.
Thanks for listening!
Update:
It happened again - and this time, we tried to solve it step by step. Result: It's all about how the file is being transmitted. I just attached the archive package to a mail to my client, that's what broke it, although I don't know why. Zipping the archive before transmitting it solved the problem, however.
After downloading XCode 4.3 beta with the IOS 5 SDK, the Organizer function to share and archive stopped working with a cryptic error "No such file or directory found".
It turns out that this is related to having two different versions of codesign_allocate . To fix the problem, do the following in a terminal window.
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate /usr/bin
Another hint - try the manual way to create a shared ipa - since it gives you a lot more detail of what went wrong. See http://blog.dmahajan.net
Can you see if this is also linked to your problem?
EasyCoder's answer fixed this issue for me - I have the 5.0 beta SDK and had the same problem.
I ran the following and it was fixed:
ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate /usr/bin/codesign_allocate