Since this problem can happen only when migrating from Linux to Windows, there is no reason to do that. This kind of transfer only happens when moving from a live to a local host. On local machines you can always use Akeeba eXtract Wizard which is 3-5 times faster than Kickstart, especially on archives with tons of files.
While modifying Kickstart itself would be possible, that would cause more problems than it would solve. Running in a web context, Kickstart has no way to determine if a write error happened because the file contains invalid characters, the host's disk quota is depleted, an operating system level error occurred or you just lack adequate permissions to write to the file. This option would lead to partially extracted backup archives reporting no error, which would subsequently lead to restoration errors. That has the potential of creating an avalanche of support requests from users believing that it was Akeeba Backup that didn't take a complete backup, not realising it was them who chose an inappropriate option for their restoration scenario. Debugging those issues over the support forum is impossible (we'd need hands-on support). That would increase the support workload and chew away the time available for developing new features, let alone it would mislead users into believing that Akeeba Backup is unstable.
So, no, I will not implement such a feature in Kickstart. If you bump into the same problem as you did, we have already documented it in our Troubleshooter Wizard and the suggested workaround is to use Akeeba eXtract Wizard. It's a lossy procedure (the file with the invalid name will not extract) but it's way much better than not being able to extract the backup archive at all :)
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!
