* This allows *runtime* validation of UEFI bootable media, such as Windows
or Linux installers, which, considering the unreliability of USB flash
drives, we assert is a a much better proposal than write-time validation
that utilities like balenaEcther (and to a lesser extent MCT) provide.
* Based on uefi-md5sum (https://github.com/pbatard/uefi-md5sum).
* Unconditionally activated on ISO extraction for GPT targets for now.
This will be changed to a user selectable option later.
* This enables the use of Ctrl-SELECT to also extract files from a .zip
when using non-bootable, DOS, UEFI-NTFS, etc.
* Also clean up some uprintf line terminations and some additional code.
* Also fix some Coverity and MinGW warnings.
* The AMI UEFI NTFS driver (version 0x10000), which is used in many modern systems from
ASUS, Gigabyte, intel and so on, has a major bug whereas depending on the size of the
buffers that are used to write the data onto the NTFS volume from Windows, as well as
read the data from the NTFS volume from UEFI, the data being read may be incorrect
(for details on this, see https://github.com/pbatard/AmiNtfsBug).
* Especially, it appears that if the size of the buffer used to write data on Windows is
smaller than the NTFS cluster size, the bug may be triggered.
* Because of this, we increase the size of ISO write buffer to 64 KB since, per
https://support.microsoft.com/en-gb/topic/default-cluster-size-for-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95
this is the maximum cluster size that can be used for NTFS volumes.
* This increase in size should also help with performance somewhat.
* Also add support for C11's _Static_assert() which may come handy.
* The legacy code we used for writing disk images used the size of the source image as
the maximum number of bytes we should copy, which is fine for uncompressed DD or VHD
images, but not so much for compressed VHDX ones. So we now make sure to use the
actual size of the virtual disk, which we obtain when mounting the VHD/VHDX.
* Also fix log progress update as well as a MinGW warning.
* Mint users sure are lucky that one of them *lied their way through* pretending that
persistence actually used to work with previous version of Mint, when it never did,
because they got us going through a whole refactor of the partition creation process
just so we could make Mint persistence work.
* Closes#2428.
* Also fix a Coverity warning.
* Use of '*.*' as pattern in file save dialog could lead to assert and crash, so
we now try to derive the type of image to be saved from the file extension. We
also did not properly handle user cancellation in the file save dialog.
* Also update iso9660/iso9660_fs.c to latest proposal of El Torito image handling.
* Also add a couple asserts in the hash table functions so that, if these ever get
triggered we will pick them from Windows Store reports, and clean up code.
* Per linuxmint/linuxmint#622 some ISOs may have a /EFI/boot/bootx64.efi that
is a symbolic to a nonexisting file.
* This is originally due to a Debian bug that was fixed in:
5bff71fea2
* Work around this by trying to extract a working bootx64.efi from the El-Torito image.
* Also improve DumpFatDir() to not replace already existing files.
* Also update copyright year and improve uprintf error handling
* Also bump GitHub Actions dependencies. Note that we do NOT want to update to
upload-artifact v4 because it BREAKS the creation of artifacts from matrix.
See: https://github.com/actions/upload-artifact#v4---whats-new
* Closes#2382
* Closes#2383
* Mint have decided to make their installation rely on a working /live/ ➔ /casper/ symlink for LMDE
thereby breaking the promise of File System Transposition that all Debian derivatives should have.
* Because of this, trying to use FAT32 with LMDE will fail, as reported in linuxmint/live-installer#152.
* Therefore, now that we can replicate symlinks on NTFS, we add an exception to always enforce the use
of NTFS for LMDE.
* For some weird reason appending the base directory to the root syslinux.cfg
we create does not appear to work with Slax. So we now always patch ldlinux.sys
to include the base directory.
* Also add an exception to move the /slax/boot/EFI directory to /EFI.
* It should be noted that, as of slax-64bit-slackware-15.0.3.iso, the Slax UEFI
Syslinux bootloaders appear to be broken (since creating a media without using
Rufus at all per the Slax documentation does *not* produce a USB drive that was
bootable in UEFI mode on 2 of the machines I tried).
* Also clean up some iso.c code and fix some unreachable code in ntfssect.c.
* Closes#2336.
* Closes#2338.
* Removes the annoyance of having to wait for the process search to complete before media creation can start.
* Also update the "Process Hacker" references to its new "System Informer" name.
* Duplicated symlinked Rock Ridge files were not counted into the total size needed
to process the image and as a result, progress could go over 100% when extracting
data (e.g. debian-live-12.1.0-amd64-lxqt.iso).
* Fix this by adding the duplicated files twice in the total block size.
* '.wic' are DD images used by the Yocto project.
* Why Yocto chose to use their own extension instead of using the de-facto '.img' is beyond me but hey...
* Also update GitHub Actions dependencies to latest.
* Closes#2319.
* Due to a typo in vhd.c where the second safe_stricmp() should be against ".vhd" and not ".vhdx" again.
* Also enable the ignore boot marker bypass for VHD/VHDX/FFU and don't misreport those images as
"compressed disk images".
* Closes#2309.
* This is placed behind an expert wall (Ctrl-Alt-E) on account that:
- If you happen to boot a Windows To Go drive in S Mode on a computer, it may set any
existing Windows installation there to S Mode as well, *even if their disk is offline!*
- It can be *exceedingly* tricky to get out of S Mode, as the SkuPolicyRequired registry
trick alone may not be enough (i.e. You can have very much a Windows install in S Mode
*without* SkuPolicyRequired being set anywhere).
* Also set version to rufus-next and fix a ChangeLog typo.
* Per https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Directory_entry it
is possible to have a FAT directory entry with a 'EFI' volume label alongside with
a 'EFI' subdirectory.
* If that happens, then the current Syslinux libfat_searchdir() code may treat the
'EFI' volume label as an empty subdirectory and say that there are no bootloaders,
even if the 'EFI\Boot\Boot###.efi' binaries really do exist.
* Fix this by filtering out entries with the 'volume label' attribute (0x08).
* For good measure, also filter out entries with the 'device' attribute (0x40), as
it is technically possible to create a 'EFI' device leading to the same issue.
* Closes#2288.
* Closes#2289.