Question
: What is an embedded CTF archive?
When a CTF archive is embedded, it is included in compiled components and extracted to a temporary folder at runtime. Each copy of your component in the file system will have its own sub-directory to which the archive is expanded. This is the default behavior, as the CTF archive is effectively hidden from users.
When the archive is not embedded ('-C' flag), it will be compiled alongside your component rather than within it, resulting in a *.ctf file being generated. The archive is only expanded once at runtime, so all copies of your application will access the same archive.
To prevent file corruption in this scenario, 'deploy locks' are used so only one instance can access the expanded archive at once. This can be disabled by setting the MCR_INHIBIT_CTF_LOCK environment variable, but it is not recommended as it can potentially cause sporadic behavior. If you choose to inhibit the deploy locks, you should make the expanded CTF archive read-only.
Question
: Why would I choose not to embed a CTF archive?
If lots of copies of your app are running simultaneously, they all reference their own CTF archive. This creates a greater time and space cost, which can become worse when the archive is expanded to a networked file system. Using the '-C' flag ensures that the archive is only extracted once, minimizing these costs.
For instance, say our application is to be distributed to a large group of coworkers. By default, each coworker would be provided an executable with an embedded CTF archive. If you wanted to update your code, you would necessarily need to update each coworker's executable. Instead, you can choose not to embed the archive, and place it in a commonly-accessible networked location. This would allow you to easily re-deploy your code and instantly have those changes reflected in your coworkers' executables, as they all reference the same CTF archive.
Not embedding the archive can also help prevent sporadic crashes for particularly complex environments.
