ISO extraction: do allocation at file creation time #1445
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some time ago a PR of mine was merged in which I added
preallocate_filesize()
to improve ISO extraction performance. However I overlooked a fairly simple way to achieve the same thing in a simpler and faster way: the nativeNtCreateFile
API accepts anAllocationSize
parameter which will accomplish the same thing. This saves two system calls per file, plus the trips to the filesystem that come with modifyingFileEndOfFileInfo
/FileAllocationInfo
.I'm aware that
winternl.h
tells users to useCreateFile
instead, but my arguments against this are:CreateFile
does not allow specifying an allocation size.NtCreateFile
is in fact extensively documented (perhaps better thanCreateFile
) as ZwCreateFile on MSDN.winternl.h
is a worthless header that purposely defines incomplete types because they are 'undocumented', which is worse than not defining them. Therefore I don't hold the opinion of whoever wrote the comment regardingCreateFile
in very high regard.CreatePreallocatedFileU
aims to be a fairly complete replacement forCreateFile
(within reason) so that it can potentially be used in other places later, although ISO extraction is probably the place where it provides the most benefit. This means it supports all flags and attributesCreateFile
does, with the exception of one: thehTemplate
parameter was removed because it is not used in Rufus, and furthermore it requires querying EAs from the filesystem, which (1) takes up an obscene amount of code, and (2) is not supported by all filesystems anyway. The code was adapted from ReactOS' CreateFileW. Both ReactOS and Rufus are licensed under the GPL so I don't believe this should be a problem.In a few rough tests I did this improves performance by 5-35% with FAT32, and 0-5% with NTFS. For FAT32, ISOs with many files (e.g. Windows XP) benefit the most, while those with most of their data in a single file (e.g. Ubuntu) only about 5%. Extracting a Windows 10 ISO is about 15% faster with FAT32.