It seems that a zip backup is not actually a zip backup (all the other formats, are tars in fact), we hit this when reporting problems with tar decompression on Windows with 7-Zip. Just to be clear, nothing wrong with tar backups on the Virtualmin side, but with the other formats like zip. Suffice to say all the other formats were exhibiting the same 7-Zip behavior because they are tars 7-Zip / Discussion / Help: .tar.gz backups from Virtualmin: when extracted via 7-Zip on Windows: shows multiple numbered folders
Can someone investigate this, maybe offer a fix, or remove the options like .zip, if not supported (would be cool to fix them though, for Windows users at least)?
I’ve asked @Jamie and @ilia if they know of any regression in this area, or if something else could explain this. Maybe zip isn’t installed on your system and some edge case bug falls back to using tar? I dunno.
Thanks for answering - yes the zip command is installed, saw this on 2 different servers both had it installed. Seems like a fallback though - maybe there is some setting somewhere I can just flip to allow?
Thank you too @Ilia for taking an interest in this. Upon on demand backups - a single domain backed to directory. So you end up with a different format that falls under that bug (maybe a bug, don’t know exactly what it could be) in 7-Zip, which has a good user base on Windows.
Downloading in the browser is another case I guess?
The only option I found regarding something about zip is in the File Manager to enforce something something, guess it is not related, used for operations in the File Manager itself.
@fakemoth We discussed it internally and Jamie mentioned that it must be fixed (to have generated backup must comply with compression format selected on UI).
Alos, would this be possible to change compression format internally? zip supports both preservation of symbolic links (using -y) and file permissions. I am asking this, because presumably, if a user chooses to download a backup in zip format, it still won’t be possible for him/her to extract it (i.e. domname_dir), as internally all files are still not in zip format.
We could certainly add those flags when running the zip command. Will this still produce an archive that is valid on other operating systems though? I suspect that the main reason for using ZIP is so that the backup can be opened on Windows.
Yes, this would be logical to have embedded/internal archives match the parent format
Do you mean even if we compress embedded files using zip internally, it still will not work on Windows because of missing .zip file extension (on embedded files)?
I suspect that the main reason for using ZIP is so that the backup can be opened on Windows.
Yes, and to open it it must internally be using zip as well.
Perhaps we could just add .zip extension to the internal files? Would that require a lot of change to backup lib when restoring?
