CORE-13525
- Newly-created partitions and unpartitioned space ar reinserted
or updated in correct order in the tree-list. Volume-creation
information data associated with the tree items is persisted
across operations.
- Reliably delete data associated to tree-list items via the
TVN_DELETEITEM notification.
This allows simplifying the cleanup function; keeping simple
the code that deletes items when deleting partitions, etc.
- Make the PrintPartitionData() function call itself recursively on
extended partitions to display the sub-list of logical partitions.
- Handle the new partition size in MB the same way as in USETUP.
- Allow existing partitions/volumes to be re-formatted, using
common code with the partition creation dialog.
- Allow selecting unpartitioned space or non-formatted partitions
for installing ReactOS: unused space will automatically be
partitioned and non-formatted partitions formatted (the user
is prompted for choosing the file system).
- Correctly zero the progress-bar position when starting file copy.
- Add missing file copy error handler in FileCopyCallback:
just copying what USETUP does.
CORE-13525
This greatly helps in reducing code complexity in some areas: code that
previously iterated over all partitions of a given disk, just to find
which ones were partitioned and contained a valid file system, now just
have to iterate over mounted volumes.
See in particular, `lib/utils/osdetect.c` and `lib/fsutil.c` .
- Remove FORMATSTATE "Preformatted" enum value;
- Cleanup osdetect code after introducing Volume support;
- Some simplifications for FormatState.
- Differentiate between 'new' partition and 'new' volume:
* "New" partition: it has been created and added in the cached list,
but not yet actually written into the disk.
* "New" volume: newly-created volume (may be backed by a partition or
not), not yet formatted. May exist on either new, or not new partition,
or elsewhere.
- Cache partition and volume NT device names.
These do not change across repartitioning operations, as long as the
partition or the filesystem volume hasn't been deleted/recreated.
This avoids doing \Device\Harddisk%u\Partition%u sprintf's everytime
we need to retrieve the given partition or volume device name.
When a partition/fileysystem volume is "virtually" created (i.e. in
the partition list, but not yet committed to disk and exposed to the
OS), no device partition number and device name are available yet.
In particular, validate that no manipulation of \Device\HarddiskM\Partition0
(i.e. the whole disk) is being made.
Addendum to commit 32e6eed760 (r63715)
CORE-5982
The function assumed that the directory path name to be created
always starts with a harddisk-partition root device name of the form:
\Device\HarddiskX\PartitionY\
Indeed, it can be (when using the volume manager) of the form:
\Device\HarddiskVolumeN\
and could even have a different format if trying to install ReactOS
on an external removable drive or other weird device.
Since the format of this prefix is not 100% always the same,
a different way to create the sub-directories is needed.
The nested-directory creation algorithm is changed as follows:
Suppose that the directory to be created is:
\Device\HarddiskVolume1\ReactOS\system32\drivers
The function first loops backwards each path component in order
to find the deepest existing sub-directory: it will try to verify
whether each of the following sub-directories exist, successively:
\Device\HarddiskVolume1\ReactOS\system32\drivers
\Device\HarddiskVolume1\ReactOS\system32\
\Device\HarddiskVolume1\ReactOS\
\Device\HarddiskVolume1\
(Notice the trailing path separators kept in this step.)
In principle, this root device FS directory must exist (since the
volume has been formatted previously). Once found, the function will
then create each of the sub-directories in turn:
\Device\HarddiskVolume1\ReactOS
\Device\HarddiskVolume1\ReactOS\system32
\Device\HarddiskVolume1\ReactOS\system32\drivers
----
An alternative to the fix could be to always specify the root device
name in a separate parameter, but this hasn't been pursued here so as
to not modify all the callers of this function.
It was introduced in commit 703eb5e8c9 (r7756) in order to hack around
the "dot"-path added in the reactos.dff generator file by the earlier
commit 3bd689f185 (r7269).
Its aim was to describe the installation directory itself, instead of
one of its sub-directories.
That _invalid_ "dot"-path was removed later by commit 027e2bfa3a (r15423);
however the '\.' hack stayed for quite a while in our code.
The correct way to describe the installation directory itself is to use
instead "\", compatible with Windows' setup, as was originally done in
txtsetup.sif, and fixed in reactos.dff(.in) in commit 97bb83fcd9 (r66604).
The idea is reminiscent of the SetupCommitFileQueue() function:
filesystem volume operations are "queued" and processed via a
"commit queue".
The commit queue uses a user-specified callback, that is used to
interact with the user whenever an operation (filesystem formatting,
checking) is started, ended, or fails, for example by displaying
appropriate UI screens and choices, etc.
See commits ebcf3cf38 and c9c6902f0 (PR #5837)
In addition, correctly set the type of extended partition being used,
depending on whether it is contained below or above the 1024-cylinder
boundary (tested on NT).
CORE-19575
For the time being, don't add read-only attribute for ease of testing
and modifying files, but it won't always stay this way.
For example, Windows sets its boot.ini (as well as NTLDR, NTDETECT.COM
etc.) as read-only (+ hidden and system) during its 1st-stage setup.
2nd-stage setup makes some adjustments in boot.ini but doesn't restore
its read-only attribute.
Windows tools that can modify boot.ini (i.e. msconfig.exe, bootcfg.exe,
and sysdm.cpl) **ALL** know how to remove the read-only attribute for
modifying boot.ini, before restoring it if needed.
The BootDrive and BootPartition values are deprecated, and support
for them will soon be removed from FreeLoader.
Add an helper function to migrate these values during ReactOS
(re)installation / update.
The support is so far enabled only for INI files (freeldr.ini, boot.ini).
May be subject to further improvements in the future.
Usage examples:
- When finding existing ReactOS or Windows installations, the boot store
should exist and is opened in read-only mode. Closing the boot store
doesn't store any temporary modifications made to it.
- When doing a clean installation, freeldr.ini is created in read-write
access.
- When installing with an existing freeldr.ini or boot.ini, they are
opened as existing files in read-write access.
- QueryBootStoreOptions(): De-duplicate code.
- SetBootStoreOpt(): Respect the FieldsToChange flag.
- BOOT_STORE_OPTIONS: Remove unused Version field and distinguish
between "Current" and "Next" BootEntryKey.
- If a section already exists, return the existing one. This allows
avoiding different section entries with the same name in the cache.
If an INI file has separate sections with the same name, their
contents (key-values) get merged into a unique section.
- If a key-value already exists, update its data value and return the
existing one. (Note that this may be subject to behaviour change in
the future.)
- Make the Create*Partition helpers take a size in bytes, not in sectors.
This allows them to be easier to use by the caller, alleviating the
need for making the size conversion into sectors. Instead it is done
internally by the helpers.
- Introduce helper macros to easily retrieve the size of a partition
entry or a disk in bytes, from their internal representation in number
of sectors.
- The 'AutoCreate' variable being USETUP-specific, remove it from the
PARTENTRY structure and use instead a flag set into the 'New' member.
- Rename IsDiskSizeValid to IsPartitionLargeEnough, to better describe
what the function is for.
Do not do that yet for extended partitions (containers).
This is possible, because when creating partitions, we do that on
unpartitioned space that is already "tagged" as either being "logical"
or not, and the partition style is inherited from that.
The resulting code is simpler, yet working as it should.
This will also help in the future for supporting other platforms, where
the concept of "primary", "extended" and "logical" partitions do not
exist (basically all platforms except BIOS-based PC-AT).
This includes:
- the default TimeText;
- the default colors.
They can however be changed by the user at one's convenience, by
explicitly specifying different values.
The upstream driver is not maintained and the file system itself
is in a semi-abandoned state.
Originally imported at 3a3ef631d1
The driver is written by Lee Jae-Hong, updated by Bo Brantén.
ReactOS porting made by Peter Hater and Pierre Schweitzer.
Follow updates at http://www.acc.umu.se/~bosse/
FS Recognizer code is left to keep the FS support as an
installable driver.
CORE-11040
The upstream driver is not maintained and the file system itself
is in a semi-abandoned state.
Originally imported at e308102f4a
The driver is written by Mark W Piper, updated by Bo Brantén.
ReactOS porting made by Peter Hater and Pierre Schweitzer.
Follow updates at http://www.acc.umu.se/~bosse/
FS Recognizer code is left to keep the FS support as an
installable driver.
CORE-11005
Add two hacks in UpdateDiskLayout() and WritePartitions() so that the
disk partition style is consistently set to a known value MBR, especially
when that disk was previously new and uninitialized (RAW).
A proper fix will be developed later when support for GPT is added.
so that they wrap the needed init steps for formatting/chkdsk'ing.
These helpers now accept a PPARTENTRY, together with the usual
formatting/chkdsk parameters. The helpers now determine the actual
NT path to use, and can perform the init steps on the partition
before performing the actual operation.
In particular, FormatPartition() is now made GPT-compliant. The
partition type retrieved by FileSystemToMBRPartitionType() is now
used as a hint for choosing FAT32 over FAT12/16, and only in the
case of a MBR partition that is *NOT* a recognized OEM partition,
it is used for updating the corresponding partition type. (OEM
partitions must retain their original type.)
The OEM partition types we (and NT) can recognize are specified
e.g. in the Microsoft Open-Specification [MS-DMRP] Appendix B
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dmrp/5f5043a3-9e6d-40cc-a05b-1a4a3617df32
Introduce an IsOEMPartition() macro to help checking for these types
(its name is based on the Is***Partition() macros from ntdddisk.h,
and from a dmdskmgr.dll export of similar name).
Instead of providing an MBR partition type to InferFileSystem(), make
it call IOCTL_DISK_GET_PARTITION_INFO(_EX) to determine whether the
partition pointed by the path/handle is MBR or GPT. Then, only if it's
MBR, we retrieve its partition type in order to "guess" an adequate file
system name, in case the latter was not recognized already via regular
ways (via GetFileSystemName() / NtQueryVolumeInformationFile()).
- Remove the GetFileSystemNameByHandle() and InferFileSystemByHandle()
functions. Instead, make the other GetFileSystemName*() and
InferFileSystem*() functions accept a HANDLE as an alternative to the
already-existing partition path string. These parameters are exclusive
to each other.
- Rename SetPartitionType() -> SetMBRPartitionType(),
and FileSystemToPartitionType() -> FileSystemToMBRPartitionType()
in order to really clarify what they do (since this code is meant
for MBR partitions only, not GPT ones).
CORE-16274
SETUPLIB:
=========
- Find the system partition initially when we create the list of
partitions.
- Split the old CheckActiveSystemPartition() helper in two helpers:
FindSupportedSystemPartition() and SetActivePartition(). This allows
simplifying slightly the former one, and allows the user, in an
interactive situation, to decide whether the "supported system
partition" found can actually be used or not.
- Remove the "OriginalSystemPartition" hack in the PARTLIST structure.
- Add a note regarding the SystemPartition member in PARTLIST.
USETUP:
=======
- Use the introduced helpers from above. If the "system" partition we
are going to use, in case we install ReactOS on a fixed disk, is *NOT*
the same as the original one (e.g. because it is detected to be not
supported by ReactOS...), display an informative screen to the user
and let him confirm whether or not he wants to change the partition.
If we install on a fixed disk, try to find a supported system partition
on the system. Otherwise if we install on a removable disk, use the
install partition as the system partition instead.
This allows providing a fix for CORE-16274.
SETUPLIB:
=========
- Remove useless HiddenSectors member in PARTENTRY structure.
- InsertDiskRegion() helper returns a BOOLEAN success.
- CreateInsertBlankRegion() helper sets LogicalPartition.
- Simplify the InitializePartitionEntry() helper so that its PartEntry
parameter is clearly the one that is being initialized (i.e. converted
from a blank region to) an actual partition, and use the helper
CreateInsertBlankRegion(). The calculations for the StartSector and
SectorCount are exactly equivalent with the old version of this
function. Also make it return a BOOLEAN success instead.
+ Add some extra validation checks.
+ Adjust CreatePrimaryPartition(), CreateExtendedPartition() and
CreateLogicalPartition() in this regard.
- Better handling of "RAW"-mounted partitions: treat them as
"Unformatted" only if they are RAW *AND* their PartitionType is one of
those associated with FAT file-system. Otherwise we cannot decide
whether they are indeed unformatted or have an unknown file-system on
them, therefore treat them as the latter.
In this regard, the IsSupportedActivePartition() helper should not
look for FileSystem == RAW but instead only look whether the partition
is Unformatted.
This should help with situations similar to the one described in CORE-16274
where a partition with a genuine file-system but not recognized by
ReactOS (because we currently do not have the EXT2/3/4 filesystem
driver loaded during 1st-stage setup due to commit 5a650f6b) and
therefore mounted as RAW, was thought to be unformatted.
USETUP:
=======
- Use the "global" SystemPartition pointer: this is the "system"
partition we will actually use. It can be different from the actual
one of the computer, for example when we install ReactOS on a
removable disk. This allows also to simplify the code.
- Remove the single-used DestinationDriveLetter variable.
- Remove BuildInstallPaths() helper and use InitDestinationPaths()
directly instead.
- Always mention the disk where the partition being formatted is.
- Cleanup old code comments, add assertions here & there...
Nowadays more and more people try to install ReactOS from removable
drives (e.g. USB sticks) onto fixed HDDs, or try to install it into
USB sticks too.
Both fixed and removable drives, as well as partitions on these, are
represented in NT using the same device name format:
\Device\HarddiskM\PartitionN ,
with an increasing disk number M. Using this number for building the
corresponding firmware-specific ARC multi(x)disk(y)rdisk(z) path used
by the NT/ROS loader (FreeLdr, ...) is then prone to error since there
may have been removable drives inserted and accounted for in the
calculation of the disk number. These drives must be correctly
subtracted in order to generate the correct ARC path, valid once all
the removable drives have been ejected (which should also be the
situation seen from the BIOS when booting up, except of course if you
boot on a USB stick).
This problem is now solved. Note that it matters only for the disks
that have also been enumerated by the firmware (BIOS; Int 13h). We
don't have to care about the other drives, since the ARC path will be
of a different format and will not use the disk number (instead, the
SCSI coordinates are used).
We also try to enumerate all the disks found in all the possible disk
adapters and controllers enumerated in the Hardware registry tree
(and that are visible by FreeLdr) in order to cover all.
Finally, we detect whether a disk reports as a "super-floppy", i.e.
an unpartitioned disk with a valid VBR. This is indeed how a standard
floppy disk looks like, or how USB sticks are partitioned on Windows.
Such disk is reported has having only one single partition starting at
the beginning of the disk, with partition number == 0, its type being
FAT16 non-bootable.
This allows us to forbid creating any new partitions on such disks.
Note that accessing either \Device\HarddiskN\Partition0 or Partition1
on such a disk returns the same data.
Note also that on the contrary, regular MBR-partitioned disks would
report at least four partitions entries, instead of just one.
The other improvements are:
- Do *NOT* write any MBR on a disk partitioned as "super-floppy".
CORE-13703
- Fix the computed disk identifier, of format: %08x-%08x-%c .
The numbers are respectively the checksum of the first sector, and
the disk signature. The terminating letter is A or X, depending
whether the first sector ends with 0x55AA/0xAA55 or not (see also
commit 5053f1f5).
- Warn if the user attempts to install ReactOS on a disk that is not
visible by the firmware of his computer, because it may not be
bootable.
- Add also some validation ASSERTs and simplify the code here and there.
- The installation partition is called "InstallPartition", while the
global "CurrentPartition" is the disk region currently selected in
the partition UI list, on which prtitioning operations are effectued.
- Extend CheckActiveSystemPartition() to use an optional alternative
disk or partition in case the actual system partition (present in the
first disk) cannot be used, e.g. because we don't support writes on it.
- Make some partitioning functions not dependent on the selected "CurrentPartition".
- Add some sanity checks.
- Improve some of the "is-partitioned" checks.
Similarly to FMIFS this structure should be private. Instead file-system
names are passed to the helper functions, allowing to use the names
returned by the FS drivers. The names are then internally mapped to the
corresponding FS providers.
In particular this allows to handle the "RAW" file-system and to assign
the 'Unformatted' flag to partitions having this FS.
Finally this helps us refining the checks performed to see whether the
current "active" system partition uses a supported file-system.
- Add checks for GPT disks and either fail or ignore the disk,
depending on the operation being executed.
[USETUP][REACTOS] Display the disk style more accurately.
CORE-7749
- Correctly insert discovered partitions in sorted order of StartSector,
and verify that they do not overlap (-> check for broken partitioning).
May help for CORE-10898.
- Use the correct reported partition numbers that may be modified after
partitioning changes, and that need to be used when opening
\Device\Harddisk'M'\Partition'N' files. This is achieving by
retrieving the returned value of the IOCTL_DISK_SET_DRIVE_LAYOUT call.
Distinguish them from the "on-disk" partition numbers that are the ones
that enumerate the partition in partition-table order (and is the order
known by e.g. the BIOS), and that should be used to construct the
destination ARC path.
May help for CORE-4870, CORE-13205.
- Simplify a lot of duplicated code by using helper functions.
