Recently my iMac G5 and my iMac Intel froze while trying scripts to automate mounting shared folders on my G5 from my Intel machine. I have to say that this is the second time in one week that the same problem occurs. I am scared of loosing my data by not understanding what is going around even if I backup religiously and am using Dropbox and Crashplan.
After freezing, the frontmost user on my G5 lost it’s Library folder and all my personnal data. Since all was synced with Dropbox, I thought I was safe. After restoring folders and files that I lost from Dropbox, I realized that most scripts and script application seemed to be corrupted. Checking the file’s info, I discovered that all «corrupted» files’s type were «Applications (classic)».
I dont understand why the file’s type has been modified. I wonder how I can change that back to «script» or «application» ?
On my Tiger (10.4) system, if I save a script with a file format of “application” (not “application bundle”) and then rip out (or otherwise lose) the resource fork, the application shows up as “Application (Classic)”. Such files will probably not actually work in Classic (the relabeling is probably just a side effect of the missing resource fork).
There may be no way to fix these resource-stripped applets. When I save two unrelated scripts as "application"s the resulting file’s data forks appear identical, indicating that the script is only stored in the resource forks of the files (which do differ). In another experiment, I grafted the resource fork from one applet onto a resource-stripped applet. When opened, it showed the script text from the ˜donor’ applet, not the original script from the stripped applet.
I know that Dropbox does not store resource forks (though it might in the future). If you restored the files from Dropbox, the missing resource forks are the likely cause of the change to “Application (Classic)”. CrashPlan says it copies resource forks. Try restoring the files from CrashPlan instead.
In the future: Avoid resource fork problems by only saving applet scripts as “application bundle” (in Show Leopard there is no “application bundle” file format, but “Application” creates application bundles).
Thanks for your great help … You are getting technical and deeper in AppleScript that I am accustomed to … I thank you very much !
You seem to be pointing out my actual problem: having restored with Dropbox. The file I want to restore was only saved by Dropbox not CrashPlan. So I will have to write that script application again … a few hours of work. The good news is that I have the full backup of all my other scripts and script applications.
You said:
I never used «application bundle» because I cannot modify the file. It would have required a double script format managing. I never had any problem on Tiger with this strategy, until this Dropbox restore. What is the point for Dropbox of not saving the resource fork ?
Do I understand that on Tiger, I should only save my script in «script» format (to be able to edit the file) and when needing an application format, I should save themonly in the «application bundle» format ? This way I will always have to alternate between the 2 format. Gush … Most of my script are saved in «application» format, preventing me of this double format managing. I also understand that this ambiguity does not exist in Snow leopard. Am I right ? If yes, is there another way to prevent the need of double format managing (like using another script editor, etc…) other than syncing these files only to CrashPlan ?
I am able to edit “application bundle” applets/droplets on my Tiger system. I just drag them to Script Editor, no need to save a separate “script” version. As long as you do not save it as “Run Only”, you should be able to edit a script saved in any file format.
As I understand it, in Snow Leopard, Apple removed the single-file-with-resource-fork “application” file format for applets/droplets. One reason was probably because that file format saved as a PowerPC application that would have to be emulated with Rosetta (which is not even installed by default in Snow Leopard). In Snow Leopard, the “Application” file format is nearly the same as the old “application bundle” file format, except the new version adds Intel-64 binaries to the previous set of PowerPC and Intel binaries. See the File Format section of the Snow Leopard AppleScript Release Notes.
Probably the reason Dropbox does not copy resource forks is because the equivalents of the resource fork on Windows and Linux are rarely used and Mac OS X is still a minority platform. Dropbox users can vote for the “Mac resource fork / extended attribute support” feature, but there is no guarantee that they will implement it. Though poking around a bit more, it seems that they are working on it. It is in the list of “in progress” requests. The note says that it will be in the 0.8 “forum builds” (sort of pre-beta, I guess).
Really any file could be affected by losing its resource fork, it depends on the applications that use them. Many common files (those that are identical between major platforms) will not use the resource fork at all. But if an application relies on the file having a resource fork, then it will be affected. I know that .webloc files used to use the resource fork, but I think the current versions of Safari only use the the data fork. Some (older?) fonts use the resource fork (exclusively) to hold the font information. There are also other pieces of metadata that are stored in xattrs alongside the resource fork (from a POSIX perspective, the resource fork is stored in an xattr). I know that Finder stores type and creator codes and “label” (color) metadata in an xattr, and I have seen files where Xcode has added an xattr to store a file’s encoding (e.g. UTF-8), though I have never noticed my Xcode do this (I think it is a Leopard feature).
Thanks again for all the time you dedicate to this thread.
My «double script format managing» problem, cannot be solve on Tiger, because there is no way to save a «launch-able script» other than by saving it in the «application» format. Most of, if not all, my scripts ends as «launch-able applications». «Script» and «application bundle» format are not «launch-able». Since the «application» format has the «resource fork» problem, I cannot use Dropbox to save those kind of file.
The good news, is that the «ressource fork» problem seems to be limited to those «application» scripts and that Dropbox will have a fix for that in a near future release.
What really scarred me was the confidence I gave to Dropbox and that they gave no warning of the problem of these files. I thought that DB could copy «any» type of file and that I could restore them without any concern. I couldn’t think that file or not «files only» and that they also have hidden parts like «resource fork».
BTW, what is the difference between the «script» and «application bundle» format ? They look really the same.
Thanks again for all that technical … my comprehension is limited, but I understand the basics.
I made a BIG mistake … Mistranslating in French is my error. What you called «application bundle», I thought that you were talking about what is labeled in french «paquet de scripts». In French «paquet» is synonymous of «bundle». The «application bundle» is called in french «Progiciel».
So, the solution to the «double format managing» would be to save all my «application» scripts on my Tiger machine to the «application bundle» format (progiciel).
So my question is now: In Tiger (OS 10.4.11) …
¢ what is the reason to have the «script» and «paquet de script» format (I don’t know what is the English translation) ?
¢ what is the reason to have the «application» and «application bundle» format ?
The “script” format (.scpt file) is useful with Apple’s AppleScript menu extra and with many ˜launcher’ applications (e.g. FastScripts, Quicksilver, etc.). Using a “script” instead of an “application” saves some overhead by not having to launch a separate, full application process (the launcher loads the script using something akin to AppleScript’s load script and runs it inside its own process). I assume the same is true of “script bundle” (.scptd folder”though the folder nature is hidden in Finder) files, but I have never found a need for “script bundle” format scripts.
You already know the primary benefit of “application” (.app file) and “application bundle” (.app folder”though the folder nature is hidden in Finder) formats: you can double-click on them and use then in any context that you might use a ˜normal’ application.
The bundle formats (“script bundle”: «paquet de script»? and “application bundle”: «Progiciel»?) were added in Mac OS X 10.3. The Bundle Programming Guide lists The Advantages of Bundles. The primary benefit is that they work on filesystems that do not support resource forks. Using a bundle format also makes it easier to modify the Info.plist file that controls various aspects of how the system uses an application bundle. The AppleScript Release Notes for 10.3 list at least one AppleScript-specific benefit: “scripting additions can be embedded within bundled applets”. This means you could develop and distribute an application that used used a particular OSAX and not require each end user to install the OSAX. It is not clear to me that the “script bundle” format shared this same benefit.