Support

Hello Paul,

If by "log files" you do mean log files, those in your backup output directory, this shouldn't happen because the PHP file scanner uses the temporary directory for its output, which is not where you should put your Akeeba Backup archives.

If by "log files" you mean "backup records", what you see in Akeeba Backup's Administer Backup Files page, this is not normal and should have never happened.

Which one of the two do you mean?

I just installed a new Joomla! 1.5.25 site and installed Akeeba Backup and Admin Tools on it, using the default settings. I took three backups, then I ran the PHP file scanner. Niether the log files nor the backup records were removed. Please try logging out of your site, clear your browser cache, close your browser then log back into your site's back-end and take a look at the Administer Backup Files page. Are any records missing now?

The only thing which could've explained this is if you were using the Akeeba Backup Lazy Plugin and a backup was underway when the scan started. Is it possible that this may have happened?

How do you erase the backup file? Are you using the Delete or Delete Files button in Akeeba Backup's Administer Backup Files page? If so, which one of the two buttons do you use? Or do you delete it using FTP?

You continue to confuse me.

Let's see if I get this straight. After taking a full site backup you have an akeeba.backend.log file in your administrator/components/com_akeeba/backup directory. When you take a PHP File Change scan this file is deleted. Is this what you are trying to say? Even that, I can't replicate. The last backup's log file stayed in the backup output directory on yet another new site.

Yes, in the meantime I have created yet another site, did everything you said you did, the backup file records in the Administer Backup Files page are not deleted. I trashed that site and created yet another one, in a different server. Same story. Third server. Same story. Fourth server. Same story. Now I just feel I've wasted an hour of my life. There is no way I can do what you say you did and achieve the same results as what you describe. Nothing related to Akeeba Backup is deleted when I use Admin Tools PHP File Change Scanner.

In fact, there is no way Admin Tools' PHP File Change Scanner can remove, add or in any way alter the backup file records of Akeeba Backup, simply because the table names set up in the platform class in Admin Tools are different than those used in Akeeba Backup. If this ever happened, Admin Tools would not list the new scan in its interface. I assume that if this happened, you'd have told me. If this happened, the scan would have actually failed, but that's another story.

Code analysis and empirical testing shows that what you report can not be replicated. Nobody else has reported anything even close to what you're saying, I can not replicate it on any other server (not just test sites, but my own live sites too), therefore it's not a bug and I'm closing this ticket.

PS: These last lines you pasted are an excerpt of the backup log file and mean that the backup was finished, the backup record was updated with the total size of the backup archive, the "None" post-processing engine was loaded (therefore nothing will be uploaded to external storage), it's done processing the one and only archive part (which is to say, the None post-processing engine confirmed that it successfully did nothing to the one and only archive part) and that the None post-processing engine notified the Akeeba Engine that it should not automatically remove the backup archive. In other words this is exactly what you expect to see on a successful backup archive.

Oh, wait, I think I know what happened. My Admin Tools package used in testing is not the same as the one published on-line. I think I have published the wrong archive which may indeed produce the bug you describe, as the name of the table used for applying the obsolete count quotas is hardcoded.

Yup, the problem was on my side, not your side. The package I have made available as 2.2.0 has this bug, indeed. Sorry. Please try using the latest dev release, rev8B803D5, from our dev releases repository. This is what I was using all along. Can you confirm that it fixes the problem you reported?

Thank you for your feedback and sorry for my insistence.