Support

These files are the installer "image" files. Whenever you create a new backup archive, their contents are transcribed into the backup archive. Without them, you cannot take a backup. If that was possible, you'd end up with a backup you cannot restore. The first time these files appeared was 19 years ago when this component was stilled called JoomlaPack. Their path is known and stable for years. I deliberately don't change these files' paths unless there is a very good reason. 

It makes no sense for me to change their extensions for several reasons.

First, it would violate the stable path policy which is used by competent hosts and software developers to avoid issues like the one you are having with your host. Punishing the people who do it right to appease the people who do it wrong is hardly sensible and it would lead to more problems down the road.

Second, changing the extension would run the risk of having the same problem. Maybe tomorrow they will decide tomorrow that .bin, or .img, or .foo –I dunno, I just made stuff up– are not allowed. I won't be playing this stupid game.

Third, the file contents and file extension should match. If I set this to a random extension which might be used by something else it would create other problems that I would be legitimately accountable for. For example, if I stupidly decided to set this to .zip then the reasonable expectation is that this should follow the ZIP format. Since it doesn't, it would create a problem with file scanners which expect to read the contents of ZIP files, therefore get reasonably deleted for being  a "suspicious" file. I would objectively have no reasonable argument to defend this kind of stupid decision. You may say "just use a generic extension like .bin". That's a great idea… except I already know that this will trigger file scanners which brings us back to the first reason I am not changing the paths of these files unless there is a legitimate reason that cannot be worked around in any other way.

Fourth, and most importantly, the problem is caused 100% by your host. It is their problem to fix, not mine. If they decide to delete files from the software you have installed despite the fact you have clearly warned them that this breaks the software, they are quite simply not providing you the service you have paid them to provide.

Fifth, and I want you to brace for this, it is trivial for them to fix their problem. They are obviously using the find command to find and delete the JPA files. It's not that hard adding exceptions to it. Here's how, it took me about 30 seconds to type this:

find /var/foobar -type d -path "*/components/com_akeebabackup/installers" -prune -o -type f -name "*.jpa" -ctime +30 -delete

Yeah. The fix is something that a child who started using Linux more than three days ago can do within a few minutes. Seasoned sysadmins like them should be able to do it with their eyes closed, and hands tied behind their back in half a minute flat. You know what this means? They do not respect you. They treat you like garbage, hoping you are too stupid to ask the right person the right question to expose their malice. Of course, you're not stupid; you're using Akeeba Backup. You asked me, in a public ticket, so here I am telling them in public that they have been exposed.

My advice is to move to a host which respects you. Moving your site is not that hard; you have Akeeba Backup to make the process much easier.

Brixly has messed with my users, so now I am properly pissed off. Here's a solution for you which beats them at their own stupid game.

Create a CRON job which runs every 9 minutes (use */9 as the minute specifier in the CRON expression, and * for the hour, month, day, and day of week specifiers) and runs the following command:

for FILE in /home/foobar/public_html/components/com_akeebabackup/installers/*.jpa; do BAK_FILE="${FILE%.jpa}.bak"; if [ ! -e "$BAK_FILE" ] || ! cmp -s "$FILE" "$BAK_FILE"; then cp "$FILE" "$BAK_FILE"; fi; done

Then, create another CRON job which runs every day, every minute (use * for all CRON expression specifiers) and runs the following command:

for FILE in /home/foobar/public_html/components/com_akeebabackup/installers/*.bak; do JPA_FILE="${FILE%.bak}.jpa"; if [ ! -e "$JPA_FILE" ]; then cp "$FILE" "$JPA_FILE"; fi; done

Here's the idea.

The first command runs every hour at minute 9, 18, 27, 36, 45, and 54. It copies the original JPA "image" files to a .bak extension e.g. brs.jpa is copied into brs.bak. This happens ONLY if the .bak file does not exist, or is different than the .jpa file.

The second command runs every minute of every hour. It copies the .bak files back to a .jpa extension but ONLY if the corresponding .jpa file does not exist at all.

Problem solved, as long as your backup does not run in those ~58 seconds of the day that the .jpa files might not exist (move your scheduled backups by a minute or two if that happens).

You're welcome!