Support

The Site Transfer Wizard will NOT delete the contents of the target site. This is something you have to do before you start transferring your site. This is by design. There are several reasons behind this, from the process being killed by the host if we try to delete the wrong folder (e.g. "logs" in Plesk) to people having folders with dozens of Gigabytes of data they don't want vanished when they are transferring a site.

The kicktemp folder cannot be removed. If it had to be created it's because of a problem with the ownership and permissions on the target server. We can create the kicktemp folder using FTP and make it writeable but by the end of the process we cannot have Kickstart remove it. You'll have to remove it manually. On the other hand, you don't need to. The only thing remaining in there is a .htaccess file which prevents direct web access to the folder.

The kickstart.transfer.php should have been deleted. I will have to look into that. Thanks!

The only folders which are created are the folders which are present in your backup archive AND the kicktemp folder. Nothing less and nothing more.

Then please point out the code where this happens - because there is no such code and it cannot be reproduced on any other site!

I mean, do you really think Kickstart would be creating a random "wordpress" folder and nobody would have told me in 3+ months? :D The average time between a release with such a bug and the first report about it is under 3 hours. That's one of the joys of having hundreds of thousands of people using the software day in and day out.

If you are not backing up a "wordpress" folder (NOTE: this includes off-site folders!) is it possible that your host is auto-installing WordPress for some reason, e.g. something you clicked / activated a lifetime ago?

Cannot be reproduced. Talk to your host.

Correction. I can reproduce when using VSFTPd on a Linux machine I set up just for this reason and PHP 7. I'm not sure if it's a bug in VSFTPd or PHP itself but there's nothing I can do about it. The transfer wizard asks PHP to see if there is a file wordpress/index.php. That's a read operation using ftp_fget. For some reason and empty folder is created(!) during that read only operation.

I believe that's a bug in VSFTPd of PHP because VSFTPd's log file states the following:

Tue Dec 19 11:21:08 2017 [pid 7071] CONNECT: Client "::ffff:127.0.0.1"
Tue Dec 19 11:21:08 2017 [pid 7070] [nicholas] OK LOGIN: Client "::ffff:127.0.0.1"
Tue Dec 19 11:21:08 2017 [pid 7072] [nicholas] FAIL DOWNLOAD: Client "::ffff:127.0.0.1", "/path/to/site/index.php
", 0.00Kbyte/sec
Tue Dec 19 11:21:08 2017 [pid 7074] CONNECT: Client "::ffff:127.0.0.1"
Tue Dec 19 11:21:08 2017 [pid 7073] [nicholas] OK LOGIN: Client "::ffff:127.0.0.1"
Tue Dec 19 11:21:08 2017 [pid 7075] [nicholas] FAIL DOWNLOAD: Client "::ffff:127.0.0.1", "/path/to/site/wordpress
/index.php", 0.00Kbyte/sec
Tue Dec 19 11:21:08 2017 [pid 7077] CONNECT: Client "::ffff:127.0.0.1"
Tue Dec 19 11:21:08 2017 [pid 7076] [nicholas] OK LOGIN: Client "::ffff:127.0.0.1"
Tue Dec 19 11:21:09 2017 [pid 7078] [nicholas] OK UPLOAD: Client "::ffff:127.0.0.1", "/path/to/site/akeeba-16.png
", 265 bytes, 429.17Kbyte/sec

There is no write operation logged anywhere. There is no other instance of "wordpress" anywhere else in the log. I double checked, right after the ftp_fget (a read only operation) we get the empty folder. I cannot reproduce it using the ftp command line client. I also can't seem to be able to reproduce this on a live site.

A "fix" for that would be the removal of the check for WordPress but I'm not sure it's the right way to do it. I added that check to make sure you're not trying to overwrite a WordPress site with a Joomla! site which is a surprisingly common mistake that can lead to an insecure site (since the leftover WordPress installation will never be updated).

So, well done, you found a bug between PHP and VSFTPd :D