Yes!!! We are finally *much* faster than 7-zip for SHA-256, even though
we are also computing MD5 and SHA-1 in parallel. Here are some averaged
comparative results, against the 5.71 GB Win10_20H2_EnglishInternational_x64.iso
(SHA-256 = 08535b6dd0a4311f562e301c3c344b4aefd2e69a82168426b9971d6f8cab35e1):
* Windows' PowerShell Get-FileHash: 48s
* 7-zip's SHA-256 : 31s
* Rufus (64-bit release version) : 23s
* Due to the partition gymnastic that is required by the hack that is ISOHybrid,
some ISOHybrid images that are written in DD mode, such as Ubuntu 20.10, may
result in Windows somehow "losing" the target disk from some of its listings.
* This "removal" can be seen for instance if you have diskpart already open and
issue 'list disk' after Rufus 3.13 completed its image writing.
* In the worst case scenario, Windows may flat out refuse to access the disk at
the sector level be it in diskpart or disk manager, which forces ones to clear
the partition tables on Linux or some other OS to be able to "recover" the disk.
* This appears to be mostly due to Windows VDS cache (which Microsoft assures
should be able to do a proper job of refreshing itself on its own, in the same
stride as they also feel the need to introduce IVdsService::Refresh whose sole
purpose appears to work around a limitation that Microsoft knows exists) not
being in sync with the actual disk layout.
* So we now add calls to VDS layout refresh where needed, to work around the issue.
* Also fix an ext2fs Coverity warning.
* For blank disks, GetVdsDiskInterface() may return success with a NULL pAdvancedDisk.
* Also silence the annoying "Failed to read label" error on ERROR_UNRECOGNIZED_VOLUME.
* When writing images such as tails, that contain a large ESP, Windows forcibly
removes the media while we are writing it, unless we lock the logical drive.
* Also fix a Bled Coverity warning.
* Remove early locking of logical volume (no longer necessary due to previous commits).
* Relax exclusive locking of physical drive when an ESP is created.
* This should help with #1637 and #1640
* Also add an extra check for sector size in WriteDrive()
* Factorize drive letter removal into a RemoveDriveLetters() call.
* Improve MountVolume() and RemountVolume() calls.
* Also bump Rufus version to 3.13
* Make sure that instantiated objects are released.
* Factorize the instantiating of disk interfaces.
* Allow the provision of an offset to delete a single partition.
* Add a ListVdsVolumes() call (which is pointless since Microsoft *CRIPPLED* its VDS implementation).
* SetAutoMount()/GetAutoMount() should check for INVALID_HANDLE_VALUE and not NULL.
Also we don't actually need to open MOUNTMGR_DOS_DEVICE_NAME rw to issue an IOCTL.
* ToggleEsp() failed to exit properly when an ESP offset was specified.
* Introduce PI_MAX to explicitly set the size of the partition_information table.
* write_sectors() has write retry, so there's no need to perform one on top of it.
* When we exit FormatThread(), GetLogicalName() should attempt to look for the the
main partition and be silent.
* Make sure that if we skip a deep directory during scan, we count at
least one block of data.
* Also produce a note about deep directory long scan times and improve
the formatting of some messages.
* Ubuntu switched to using GRUB for BIOS, so our update_md5sum() code was not being called.
* Move update_md5sum() to being called unconditionally to fix this.
* Closes#1616 (again...)
* GRUB have cherry-picked patches from the "BootHole" vulnerability fix at
https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00034.html and
have applied them to their 2.04 GRUB loader.
* This results in breakage with "error: symbol 'grub_calloc' not found" when
using the release GRUB 2.04 version of core.img.
* Therefore, we too cherry-picked some patches to apply on top of GRUB 2.04
release to make our core.img compatible with Ubuntu 20.10.
* Closes#1616
* Also increase the maximum write stride for ms-sys to 64 KB (required to
write the GRUB 2.05 bootloader which is larger than 32 KB) and update hash DB.
* The presence of a > 4 GB file forces the use of NTFS which is incompatible with
SysLinux 4.x or earlier. As such, if an image uses SysLinux only, there's no
point in enabling MBR as SysLinux won't boot.
* Required for ISOs such as securityonion-2.0.1-rc1.iso.
* Commit 77d319267f broke lookup of ISO filenames since iso9660_open()
enabled the Rock Ridge extensions by default, despite using ISO_EXTENSION_NONE
for the internal call, and we addressed a FIXME related to this.
* This resulted in Rufus not being able to lookup 'boot/grub/i386-pc/normal.mod' to parse GRUB's
version, since without Rock Ridge, 'i386-pc/' is unable to match the ISO-9660 'I386_PC/' dir.
* Closes#1573 and addresses part of #1616.
* Also fix a MinGW compilation warning.
* These bootloaders will require LFN support. Since we don't expect that
many people to create bootable media for RISC-V derived from bootloaders
contained in a 'efi.img`, we simply ignore these for now.
* Don't use hDrive handle for longer than necessary
* Move all the popcount() function calls into missing.h
* Ensure that the thread_affinity[] array is properly sized
* Improve timeouts for conflicting process search
* A user is reporting that, on one of their platforms, Rufus is writing to the wrong target during the file-copy
phase and using their existing Y: local drive instead of the drive associated to the USB, despite the fact
that Rufus is passing the right volume name to GetVolumePathNamesForVolumeName().
* Here's the PowerShell wmic output, confirming that the volume GUID obtained by Rufus is the right one:
DriveLetter : Y:
DeviceId : \\?\Volume{000349b1-17d0-69f6-c13f-f31162930600}\
Capacity : 118540464128
FileSystem : NTFS
Label : Y-DISK
DriveLetter : H:
DeviceId : \\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\
Capacity : 15791824896
FileSystem : FAT32
Label : ADATA16GB
* And here's the Rufus log demonstrating that GetVolumePathNamesForVolumeName() is returning the *WRONG* letter:
Found volume \\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\
\\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\ is already mounted as Y: instead of H: - Will now use this target instead...
* The last line shows, without the shadow of a doubt, that we did feed "\\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\" to
GetVolumePathNamesForVolumeName() and that this API call was successful (returned a non zero size) but ultimately returned
the wrong letter (Y: instead of H:)...
* Therefore, Windows is BUGGY and the use of GetVolumePathNamesForVolumeName() must be avoided.
* ISOs with tons of Rock Ridge deep directory entries (such as OPNsense)
can be very slow to scan due to the nature of deep directory parsing,
which requires processing the whole ISO9660 fs, for each deep directory
file, in order to find the relevant LSN entry.
* Since we don't expect much of the content we care about to reside in a
deep directory entry, we amend the code to cut short the scan of any
directory that contains such elements.
* Note that this only applies for ISO scan and it does nothing to speed
up the ISO extraction process.
* Related to issue #1575
