[Nexus One Android Development] tkirton:
Don't worry about it. It only replaces the app when you execute a2sd fixmarket. This was to address an issue with a disappearing market, but since then the problem has been pointed to zipalign (which is why zipalign won't run automatically at boot).

I think PF4a doesn't even have the command anymore, so, unless you manually push it from /data/a2sd, it won't replace anything.

The upcoming RC1 version will have that removed, as it is no longer needed.

Here's how Darktremor Apps2SD works:

1. First thing it does is transfer control to launcha2sd, which is ran by using bash instead of sh (bash seems to be more stable).

2. Once launcha2sd is running, it performs a quick test to see if you are asking for help (a2sd help). If so, it displays the contents of the help file and exits.

3. Next, it checks to see if the following properties are in the init.rc:

- cm.filesystem.ready or dc.filesystem.ready (only one has to be present)

If so, it can run the more advanced boota2sd. If not, it will run a basic version of Apps2SD (FYI, these properties actually are used to stop the init.rc until Apps2SD [and any other script the rom developer deems necessary to run] are complete. This prevents dalvikvm from interferring, preventing a race condition).

4. Next, it runs starta2sd unless you don't have the properties stated before, then it continues by moving the /data/app and /data/app-private to SD card (if needed and after attempting to mount the ext partition). Then it activates swap (if available) then it exits.

5. Under starta2sd, it checks to see if a command was requested (install, remove, cachesd, cachepart, jit, nojit, etc...). If so, it runs the appropriate commands for the command requested.

6. If no command was given, it checks to see if apps2sd is being ran for the first time. If so, it transfers control to boota2sd. If not, it displays a message stating you need to supply a command and promptly exits.

7. In boota2sd, it checks for the old flag files (from version 2.5 - 2.7) and moves them to the /data directory.

8. Next, boota2sd attempts to mount the ext partition. If that fails, it will engage Boot Loop Protection, which puts your /data/app, /data/app-private and /data/dalvik-cache (if it is stored on the SD card) back to internal storage and sets the No Apps2SD flag file. This can be reversed by executing a2sd install once the issue with the ext partition is fixed.

9. Next, it checks for flag files and whether the correct setup exists. If not (say you have the Dalvik to SD cache flag file active but your dalvik-cache is being stored on your internal storage), the program initiates auto-repair.

10. Once that is complete, it checks to see if it needs to move applications to the SD card and moves them, unless the No Apps2SD flag file is present.

11. Next, it looks to see if the user has activated ZipAlign on boot (a2sd zipalign) and, if so, will proceed to zipalign the /data/app and /data/app-private directories.

12. Next, it activates the swap partition, unless the swap partition isn't present or the No Swap flag file is set.

13. The program then ends.

This is the automated boot sequence. You can control the behavior of apps2sd by using commands (a2sd install, a2sd cachepart, a2sd align...)

System files are only modified if there is a need to (i.e. JIT) and only if the user activates the correct command (i.e. a2sd jit, a2sd nojit). In fact, the only time the /system partition is changed to a read-write state is during the JIT installation (and that is changed back to read-only when the setup is complete)...otherwise, the /system partition is read-only through the entire Apps2SD run.