As a number of AIR developers have discovered, it’s hard—but not impossible—to write files in the application’s install directory. That’s the same location given by File.applicationDirectory.
Granted, it’s often a tempting thing to do. For example, many applications include a database or configuration file with some pre-filled data. Once installed, they often want to update that file, say with user-specific data or preferences.
The first problem with this is that it’s not reliable. On some operating systems—Vista, for example—the installation directory is protected by the operating system. Even if AIR lets you write to this location Vista won’t. So if you want to write portable applications, don’t do this.
The second problem with this is that it’s not safe. Any code written into this directory runs with application privilege, which can compromise your application, which can compromise the user’s machine. That’s why Vista protects these directories.
The third problem is that it invalidates your application’s signature. Among other things, that means you won’t have access to the encrypted local store any more.
It’s also unnecessary. A safe and allowable alternative is to write somewhere into the user’s directory. If you still want a starter file, it’s easy to copy one from your install directory to the per-user location. Note that this also avoid problems if there are multiple users on the same machine.
In order to help developers avoid this pattern, AIR will prevent write access to this directory in most cases, and even when the underlying operating system allows it. There are currently ways around this, as it’s advisory—not mandatory. However, the ability to go around this restriction is often misinterpreted as a defect, and we may close this off in a future release. You’ve been warned.