I have two Macs, and a shared folder on a third Windows computer. If I do something like this:
Copy an executable console application (not a .app file - a single file which is executable) from Mac 1 to Windows machine
Zip executable on Windows machine
Copy new zip file to Mac 2 and unzip
The file that comes out of the zip file is still executable. How is the "executable-ness" nature of that file preserved, given that windows permissions system is totally different and doesn't really have the concept of executable files?
OSX Apps are folders, not files. When copying folders to a file system, that doesn't have executable bit representation, OSX creates hidden files for the missing attributes. Zipping the App is zipping a folder, including its hidden subfolders. On copy back, OSX will recreate the missing properties from the hidden files.
These hidden folders are called ._.OriginalName
EDIT
After quite extensive discussion in the comments sections, here is a bit of info about simple executable files (execute permission set) as opposed to *.app folders (native OSX applications)
Ofcourse OSX honours the executable permissions, (set and unset)
Copying a file to a file system, that does not have a concept of an executable permission (most prominently FAT formated USB sticks), then copying it back after a rename on another OS leaves OSX with the dilemma of whether to see the file as executable or not - the ._.OriginalName metadata store is decoupled from the file by the rename
OSX solves this dilemma by setting the permissions to 700 or 777, thus making every file executable
Related
I have a UNIX executable file which could be executed by just clicking it. I uploaded it to a cloud service, and then downloaded it on another Mac computer. Now this Mac doesn't recognise it as an executable file anymore. So I have to use the chmod +x command. Is there any way to keep the executable nature of the file intact, upon upload and download from the internet?
I could use the chmod +x command to make the downloaded file executable. But it was originally executable. I don't understand why this mode is changed upon upload and download from the internet.
Different cloud services will have different behavior with respect to preserving the Unix file modes and ACLs. When uploaded to a cloud service, the files may be stored on a different type of filesystem or may not be stored as files at all.
On my mac I copied a file to iCloud Drive and the executable mode was preserved. Microsoft OneDrive also preserved the executable mode. Both iCloud Drive and OneDrive integrate with Finder.
You may consider using tar or gzip to create an archive file containing your executable. The archive format will preserve the file modes and the archive file can be stored on any cloud service.
I have created an installer program for my application using NWJS. I need to package the NWJS app into a single exe. I was going to use windows iexpress becasue that would provide exactly the function I need, however I can't use that because it does not support directorys inside the archive and even with the app html files packaged into package.nw NWJS still requires the locales directory to run and also iexpress has some security flaws.
Basically I need something like this:
1: it is a single portable executable file which contains some sort of archive with the nwjs files in it.
2: when the exe is run it extracts the archive to a temporary directory and runs nwjs.
3: when nwjs exits it deletes the temp directory.
So far I have not found any way of doing this.
I did some more research and solved it myself by using Enigma Virtual Box.
http://enigmaprotector.com/en/downloads.html
I am running .py files from a read-only network folder (via Python 2.7 on Windows). Are pyc files still generated? And if so, where do they go?
The contents are generated by the compiler, but they are simply not saved (a loader may set an alternate __cached__, but normally doesn't). The .pyc files are merely used to cache the result of the compilation. distutils.util.byte_compile has some documentation links for further details.
I recently received the following comment from the reviewer of one of my add-ons at the official Mozilla Add-ons website:
The permissions in your XPI are broken. Most files and directories do not have the expected read and execute permissions, or indeed any permissions at all.
I wasn't aware that file permissions were an issue in XPI files. To my knowledge, none of the files in my XPI need the execute bit set (I only package standard stuff: XUL, JavaScript, CSS, etc). I create my XPI in Windows using the Cygwin zip tool, and since Windows knows nothing about file permissions, they aren't stored as they would be in Linux.
What file permissions are expected for file and directory entries in an XPI? The Extension Packaging page at MDN has the following quote, but no associated details on what they should be:
... you must verify that the file system permissions for the directories and files for the extension are set properly. Otherwise, the Extension Manager may not function properly with the extension or the extension itself may not work properly.
This is typically an issue if you create the extension package on Windows but the extension is used on Linux or OS X later - Windows doesn't have any file permissions to be put into a ZIP archive and unpacking on Linux or OS X sometimes creates bogus file permissions (000 rather than the usual 755 or 644). You could try using a different ZIP packer, e.g. Info-ZIP that doesn't cause such issues for me. Better yet, don't require your extension to be unpacked at all - <em:unpack> is often used but rarely really required.
So from what little I understand about packaging for Macs, I see that the actual program that launches is the one defined under the CFBundleExecutable key in Info.plist.
<key>CFBundleExecutable</key>
<string>JavaApplicationStub</string>
Now, my app doesnt work if /APP/Content/MacOS/JavaApplicationStub is not chmodded +x (It just fails silently without doing anything, which is a pain!).
Fair enough, its not executable I guess. But its a big problem if you are copying the app from somewhere that dosent support +x properties on files; such as windows, fat32 USB keys, CDROMs, websites, zip files, etc...
What can I do in these instances to make the app able to run? Manually setting the execute bit is not an option.
There's got to be people who run Mac apps off CD, at the very least!
I think your only option is to package the APP bundle into a DMG file, or tar.
DMG is more standard and just as easy to do as using tar or zipping. The command line we use is:
hdiutil create -srcfolder Last.fm.app -format UDZO -imagekey zlib-level=9 -scrub Last.fm.dmg
You can tar from any platform, (even Windows, if you install cygwin, or use the GNU standalone, http://gnuwin32.sourceforge.net/packages/gtar.htm)
tar cf app.tar app_directory
With gzip compression:
tar czf app.tar.gz app_directory
#mxcl, that works, sort of, thanks. However, you need to be on a Mac to run hdiutil :(.
Also, it mucks up the paths of the app... there were some files(like the db file) that were not inside the .app folder, and thus are not included in the .DMG file.
Im building on windows, and the app is getting deployed to removable media. The whole point is to avoid installing anything.
The app runs on windows aswell, so there is a windows .exe alongside the mac.app on the root of the disk. There is also a sqllite.db file that both versions of the application share. Multi-platform is hard :/