Intravision/reactos
1
0
Fork 0
mirror of https://github.com/reactos/reactos.git synced 2024-12-28 01:55:19 +00:00
Code Issues Projects Releases Packages Wiki Activity
reactos/base/setup/lib/fsutil.c

1313 lines
42 KiB
C
Raw Normal View History

[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
/*
* PROJECT: ReactOS Setup Library
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
* LICENSE: GPL-2.0-or-later (https://spdx.org/licenses/GPL-2.0-or-later)
* PURPOSE: Filesystem Format and ChkDsk support functions
* COPYRIGHT: Copyright 2003-2019 Casper S. Hornstrup <chorns@users.sourceforge.net>
* Copyright 2017-2024 Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
*/
//
// See also: https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/fmifs/init.c;h=e895f5ef9cae4806123f6bbdd3dfed37ec1c8d33;hb=b9db9a4e377a2055f635b2fb69fef4e1750d219c
// for how to get FS providers in a dynamic way. In the (near) future we may
// consider merging some of this code with us into a fmifs / fsutil / fslib library...
//
/* INCLUDES *****************************************************************/
#include "precomp.h"
#include "partlist.h"
[SETUPLIB] Move the filesystem recognition helpers to their own file.
2020-10-11 21:42:02 +00:00
#include "fsrec.h"
[SETUPLIB] Code re-organization in bootsup.c and fsutil.c. - Move the actual VBR bootcode installation helpers into fsutil.c (they depend on the selected filesystem). - Introduce InstallBootCodeToDisk() and InstallBootCodeToFile() and bootcode.c helpers, in order to replace the several functions that were duplicating the same code.
2020-10-17 18:29:47 +00:00
#include "bootcode.h"
[SETUPLIB] Move the filesystem recognition helpers to their own file.
2020-10-11 21:42:02 +00:00
#include "fsutil.h"
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
#include <fslib/vfatlib.h>
[USETUP][SETUPLIB] Added support for formatting partition in BTRFS and installing ReactOS on it. Removed code related to EXT2 boot sector for now. CORE-13769
2018-06-13 23:30:06 +00:00
#include <fslib/btrfslib.h>
[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib. - Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem. - The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP. - Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list. - Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...). svn path=/branches/setup_improvements/; revision=74572 svn path=/branches/setup_improvements/; revision=74573
2017-05-17 23:31:52 +00:00
// #include <fslib/ext2lib.h>
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
// #include <fslib/ntfslib.h>
#define NDEBUG
#include <debug.h>
[SETUPLIB] Code re-organization in bootsup.c and fsutil.c. - Move the actual VBR bootcode installation helpers into fsutil.c (they depend on the selected filesystem). - Introduce InstallBootCodeToDisk() and InstallBootCodeToFile() and bootcode.c helpers, in order to replace the several functions that were duplicating the same code.
2020-10-17 18:29:47 +00:00
/* TYPEDEFS *****************************************************************/
#include <pshpack1.h>
typedef struct _FAT_BOOTSECTOR
{
UCHAR JumpBoot[3]; // Jump instruction to boot code
CHAR OemName[8]; // "MSWIN4.1" for MS formatted volumes
USHORT BytesPerSector; // Bytes per sector
UCHAR SectorsPerCluster; // Number of sectors in a cluster
USHORT ReservedSectors; // Reserved sectors, usually 1 (the bootsector)
UCHAR NumberOfFats; // Number of FAT tables
USHORT RootDirEntries; // Number of root directory entries (fat12/16)
USHORT TotalSectors; // Number of total sectors on the drive, 16-bit
UCHAR MediaDescriptor; // Media descriptor byte
USHORT SectorsPerFat; // Sectors per FAT table (fat12/16)
USHORT SectorsPerTrack; // Number of sectors in a track
USHORT NumberOfHeads; // Number of heads on the disk
ULONG HiddenSectors; // Hidden sectors (sectors before the partition start like the partition table)
ULONG TotalSectorsBig; // This field is the new 32-bit total count of sectors on the volume
UCHAR DriveNumber; // Int 0x13 drive number (e.g. 0x80)
UCHAR Reserved1; // Reserved (used by Windows NT). Code that formats FAT volumes should always set this byte to 0.
UCHAR BootSignature; // Extended boot signature (0x29). This is a signature byte that indicates that the following three fields in the boot sector are present.
ULONG VolumeSerialNumber; // Volume serial number
CHAR VolumeLabel[11]; // Volume label. This field matches the 11-byte volume label recorded in the root directory
CHAR FileSystemType[8]; // One of the strings "FAT12 ", "FAT16 ", or "FAT "
UCHAR BootCodeAndData[448]; // The remainder of the boot sector
USHORT BootSectorMagic; // 0xAA55
} FAT_BOOTSECTOR, *PFAT_BOOTSECTOR;
C_ASSERT(sizeof(FAT_BOOTSECTOR) == FAT_BOOTSECTOR_SIZE);
typedef struct _FAT32_BOOTSECTOR
{
UCHAR JumpBoot[3]; // Jump instruction to boot code
CHAR OemName[8]; // "MSWIN4.1" for MS formatted volumes
USHORT BytesPerSector; // Bytes per sector
UCHAR SectorsPerCluster; // Number of sectors in a cluster
USHORT ReservedSectors; // Reserved sectors, usually 1 (the bootsector)
UCHAR NumberOfFats; // Number of FAT tables
USHORT RootDirEntries; // Number of root directory entries (fat12/16)
USHORT TotalSectors; // Number of total sectors on the drive, 16-bit
UCHAR MediaDescriptor; // Media descriptor byte
USHORT SectorsPerFat; // Sectors per FAT table (fat12/16)
USHORT SectorsPerTrack; // Number of sectors in a track
USHORT NumberOfHeads; // Number of heads on the disk
ULONG HiddenSectors; // Hidden sectors (sectors before the partition start like the partition table)
ULONG TotalSectorsBig; // This field is the new 32-bit total count of sectors on the volume
ULONG SectorsPerFatBig; // This field is the FAT32 32-bit count of sectors occupied by ONE FAT. BPB_FATSz16 must be 0
USHORT ExtendedFlags; // Extended flags (fat32)
USHORT FileSystemVersion; // File system version (fat32)
ULONG RootDirStartCluster; // Starting cluster of the root directory (fat32)
USHORT FsInfo; // Sector number of FSINFO structure in the reserved area of the FAT32 volume. Usually 1.
USHORT BackupBootSector; // If non-zero, indicates the sector number in the reserved area of the volume of a copy of the boot record. Usually 6.
UCHAR Reserved[12]; // Reserved for future expansion
UCHAR DriveNumber; // Int 0x13 drive number (e.g. 0x80)
UCHAR Reserved1; // Reserved (used by Windows NT). Code that formats FAT volumes should always set this byte to 0.
UCHAR BootSignature; // Extended boot signature (0x29). This is a signature byte that indicates that the following three fields in the boot sector are present.
ULONG VolumeSerialNumber; // Volume serial number
CHAR VolumeLabel[11]; // Volume label. This field matches the 11-byte volume label recorded in the root directory
CHAR FileSystemType[8]; // Always set to the string "FAT32 "
UCHAR BootCodeAndData[420]; // The remainder of the boot sector
USHORT BootSectorMagic; // 0xAA55
} FAT32_BOOTSECTOR, *PFAT32_BOOTSECTOR;
C_ASSERT(sizeof(FAT32_BOOTSECTOR) == FAT32_BOOTSECTOR_SIZE);
typedef struct _BTRFS_BOOTSECTOR
{
UCHAR JumpBoot[3];
UCHAR ChunkMapSize;
UCHAR BootDrive;
ULONGLONG PartitionStartLBA;
UCHAR Fill[1521]; // 1536 - 15
USHORT BootSectorMagic;
} BTRFS_BOOTSECTOR, *PBTRFS_BOOTSECTOR;
C_ASSERT(sizeof(BTRFS_BOOTSECTOR) == BTRFS_BOOTSECTOR_SIZE);
[SETUPLIB] Add NTFS boot support. (#3778)
2022-10-19 00:02:24 +00:00
typedef struct _NTFS_BOOTSECTOR
{
UCHAR Jump[3];
UCHAR OEMID[8];
USHORT BytesPerSector;
UCHAR SectorsPerCluster;
UCHAR Unused0[7];
UCHAR MediaId;
UCHAR Unused1[2];
USHORT SectorsPerTrack;
USHORT Heads;
UCHAR Unused2[4];
UCHAR Unused3[4];
USHORT Unknown[2];
ULONGLONG SectorCount;
ULONGLONG MftLocation;
ULONGLONG MftMirrLocation;
CHAR ClustersPerMftRecord;
UCHAR Unused4[3];
CHAR ClustersPerIndexRecord;
UCHAR Unused5[3];
ULONGLONG SerialNumber;
UCHAR Checksum[4];
UCHAR BootStrap[426];
USHORT EndSector;
UCHAR BootCodeAndData[7680]; // The remainder of the boot sector (8192 - 512)
} NTFS_BOOTSECTOR, *PNTFS_BOOTSECTOR;
C_ASSERT(sizeof(NTFS_BOOTSECTOR) == NTFS_BOOTSECTOR_SIZE);
[SETUPLIB] Code re-organization in bootsup.c and fsutil.c. - Move the actual VBR bootcode installation helpers into fsutil.c (they depend on the selected filesystem). - Introduce InstallBootCodeToDisk() and InstallBootCodeToFile() and bootcode.c helpers, in order to replace the several functions that were duplicating the same code.
2020-10-17 18:29:47 +00:00
// TODO: Add more bootsector structures!
#include <poppack.h>
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
/* LOCALS *******************************************************************/
/** IFS_PROVIDER **/
typedef struct _FILE_SYSTEM
{
PCWSTR FileSystemName;
[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions. [AUTOCHK] Add also support for scanning FATX volumes. The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the U*.DLL user-mode FS library dlls are different (and have different prototypes) than the similarly-named functions exported by FMIFS.DLL . In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()" in our U*.DLL libraries actually correspond more, from their arguments, to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their *Ex() counterparts instead take most of the parameters through a structure passed by pointer. On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these *Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx() call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls U*.DLL!FormatEx() (that we do not implement yet either) !! To improve that, refactor the calls to these U*.DLL functions so as to respect the more compatible prototypes: They contain the correct number of parameters in a compatible order. However, some of the parameters do not have the same types yet: the strings are kept here in PUNICODE_STRINGS, while on Windows they are passed via an undocumented DSTRING struct, and the FMIFS callback is instead a MESSAGE struct/class on Windows. Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used in the corresponding FMIFS.DLL functions. One thing to notice is that the U*.DLL!Format() (and the Ex) functions support a BOOLEAN (a flag resp.) for telling that a backwards-compatible FS version should be used instead of the (default) latest FS version. This is used e.g. by the FAT FS, where by default FAT32 is selected (depending also on other constraints like, the disk and the partition sizes), unless that bit is set in which case, FAT16 (or 12) is used.
2020-11-22 04:35:37 +00:00
PULIB_FORMAT FormatFunc;
PULIB_CHKDSK ChkdskFunc;
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
} FILE_SYSTEM, *PFILE_SYSTEM;
[SETUPLIB] Re-enable the filesystem detection code based on recognition by FSDs.
2018-11-12 23:13:45 +00:00
/* The list of file systems on which we can install ReactOS */
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
static FILE_SYSTEM RegisteredFileSystems[] =
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
{
[USETUP][SETUPLIB] Continue hiding the FAT32 format in the format list, but take it into account anyway later on. The formatter will select it anyway as soon as the partition size permits it. We make it available internally however so as to "emulate" FMIFS functionality. Now rely on the partition filesystem for InstallVBRToPartition() instead of the unreliable and deprecated partition type.
2020-10-19 21:49:26 +00:00
/* NOTE: The FAT formatter will automatically
* determine whether to use FAT12/16 or FAT32. */
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
{ L"FAT" , VfatFormat, VfatChkdsk },
[USETUP][SETUPLIB] Continue hiding the FAT32 format in the format list, but take it into account anyway later on. The formatter will select it anyway as soon as the partition size permits it. We make it available internally however so as to "emulate" FMIFS functionality. Now rely on the partition filesystem for InstallVBRToPartition() instead of the unreliable and deprecated partition type.
2020-10-19 21:49:26 +00:00
{ L"FAT32", VfatFormat, VfatChkdsk },
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
#if 0
[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib. - Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem. - The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP. - Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list. - Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...). svn path=/branches/setup_improvements/; revision=74572 svn path=/branches/setup_improvements/; revision=74573
2017-05-17 23:31:52 +00:00
{ L"FATX" , VfatxFormat, VfatxChkdsk },
{ L"NTFS" , NtfsFormat, NtfsChkdsk },
[USETUP][SETUPLIB] Added support for formatting partition in BTRFS and installing ReactOS on it. Removed code related to EXT2 boot sector for now. CORE-13769
2018-06-13 23:30:06 +00:00
#endif
[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions. [AUTOCHK] Add also support for scanning FATX volumes. The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the U*.DLL user-mode FS library dlls are different (and have different prototypes) than the similarly-named functions exported by FMIFS.DLL . In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()" in our U*.DLL libraries actually correspond more, from their arguments, to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their *Ex() counterparts instead take most of the parameters through a structure passed by pointer. On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these *Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx() call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls U*.DLL!FormatEx() (that we do not implement yet either) !! To improve that, refactor the calls to these U*.DLL functions so as to respect the more compatible prototypes: They contain the correct number of parameters in a compatible order. However, some of the parameters do not have the same types yet: the strings are kept here in PUNICODE_STRINGS, while on Windows they are passed via an undocumented DSTRING struct, and the FMIFS callback is instead a MESSAGE struct/class on Windows. Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used in the corresponding FMIFS.DLL functions. One thing to notice is that the U*.DLL!Format() (and the Ex) functions support a BOOLEAN (a flag resp.) for telling that a backwards-compatible FS version should be used instead of the (default) latest FS version. This is used e.g. by the FAT FS, where by default FAT32 is selected (depending also on other constraints like, the disk and the partition sizes), unless that bit is set in which case, FAT16 (or 12) is used.
2020-11-22 04:35:37 +00:00
{ L"BTRFS", BtrfsFormat, BtrfsChkdsk },
[USETUP][SETUPLIB] Added support for formatting partition in BTRFS and installing ReactOS on it. Removed code related to EXT2 boot sector for now. CORE-13769
2018-06-13 23:30:06 +00:00
#if 0
[SETUPLIB] Re-enable the filesystem detection code based on recognition by FSDs.
2018-11-12 23:13:45 +00:00
{ L"EXT2" , Ext2Format, Ext2Chkdsk },
{ L"EXT3" , Ext2Format, Ext2Chkdsk },
{ L"EXT4" , Ext2Format, Ext2Chkdsk },
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
#endif
};
/* FUNCTIONS ****************************************************************/
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
/** QueryAvailableFileSystemFormat() **/
BOOLEAN
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
GetRegisteredFileSystems(
IN ULONG Index,
OUT PCWSTR* FileSystemName)
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
{
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
if (Index >= ARRAYSIZE(RegisteredFileSystems))
return FALSE;
*FileSystemName = RegisteredFileSystems[Index].FileSystemName;
return TRUE;
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
}
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
/** GetProvider() **/
static PFILE_SYSTEM
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
GetFileSystemByName(
IN PCWSTR FileSystemName)
{
#if 0 // Reenable when the list of registered FSes will again be dynamic
PLIST_ENTRY ListEntry;
PFILE_SYSTEM_ITEM Item;
ListEntry = List->ListHead.Flink;
while (ListEntry != &List->ListHead)
{
Item = CONTAINING_RECORD(ListEntry, FILE_SYSTEM_ITEM, ListEntry);
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
if (Item->FileSystemName &&
[SETUPLIB][USETUP] FS utilities: Use the ISO C and C++ conformant name: _wcsicmp Stop using non-conforming wcsicmp. See also PR #6925 by Timo Kreuzer.
2024-06-26 11:46:48 +00:00
(_wcsicmp(FileSystemName, Item->FileSystemName) == 0))
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
{
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
return Item;
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
}
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
ListEntry = ListEntry->Flink;
}
#else
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
ULONG Count = ARRAYSIZE(RegisteredFileSystems);
PFILE_SYSTEM FileSystems = RegisteredFileSystems;
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
ASSERT(FileSystems && Count != 0);
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
while (Count--)
{
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
if (FileSystems->FileSystemName &&
[SETUPLIB][USETUP] FS utilities: Use the ISO C and C++ conformant name: _wcsicmp Stop using non-conforming wcsicmp. See also PR #6925 by Timo Kreuzer.
2024-06-26 11:46:48 +00:00
(_wcsicmp(FileSystemName, FileSystems->FileSystemName) == 0))
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
{
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
return FileSystems;
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
}
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
++FileSystems;
}
#endif
return NULL;
}
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
/** ChkdskEx() **/
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
ChkdskFileSystem_UStr(
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
_In_ PUNICODE_STRING DriveRoot,
_In_ PCWSTR FileSystemName,
_In_ BOOLEAN FixErrors,
_In_ BOOLEAN Verbose,
_In_ BOOLEAN CheckOnlyIfDirty,
_In_ BOOLEAN ScanDrive,
_In_opt_ PFMIFSCALLBACK Callback)
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
{
PFILE_SYSTEM FileSystem;
[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions. [AUTOCHK] Add also support for scanning FATX volumes. The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the U*.DLL user-mode FS library dlls are different (and have different prototypes) than the similarly-named functions exported by FMIFS.DLL . In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()" in our U*.DLL libraries actually correspond more, from their arguments, to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their *Ex() counterparts instead take most of the parameters through a structure passed by pointer. On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these *Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx() call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls U*.DLL!FormatEx() (that we do not implement yet either) !! To improve that, refactor the calls to these U*.DLL functions so as to respect the more compatible prototypes: They contain the correct number of parameters in a compatible order. However, some of the parameters do not have the same types yet: the strings are kept here in PUNICODE_STRINGS, while on Windows they are passed via an undocumented DSTRING struct, and the FMIFS callback is instead a MESSAGE struct/class on Windows. Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used in the corresponding FMIFS.DLL functions. One thing to notice is that the U*.DLL!Format() (and the Ex) functions support a BOOLEAN (a flag resp.) for telling that a backwards-compatible FS version should be used instead of the (default) latest FS version. This is used e.g. by the FAT FS, where by default FAT32 is selected (depending also on other constraints like, the disk and the partition sizes), unless that bit is set in which case, FAT16 (or 12) is used.
2020-11-22 04:35:37 +00:00
NTSTATUS Status;
BOOLEAN Success;
[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib. - Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem. - The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP. - Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list. - Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...). svn path=/branches/setup_improvements/; revision=74572 svn path=/branches/setup_improvements/; revision=74573
2017-05-17 23:31:52 +00:00
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
FileSystem = GetFileSystemByName(FileSystemName);
[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib. - Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem. - The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP. - Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list. - Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...). svn path=/branches/setup_improvements/; revision=74572 svn path=/branches/setup_improvements/; revision=74573
2017-05-17 23:31:52 +00:00
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
if (!FileSystem || !FileSystem->ChkdskFunc)
{
[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions. [AUTOCHK] Add also support for scanning FATX volumes. The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the U*.DLL user-mode FS library dlls are different (and have different prototypes) than the similarly-named functions exported by FMIFS.DLL . In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()" in our U*.DLL libraries actually correspond more, from their arguments, to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their *Ex() counterparts instead take most of the parameters through a structure passed by pointer. On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these *Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx() call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls U*.DLL!FormatEx() (that we do not implement yet either) !! To improve that, refactor the calls to these U*.DLL functions so as to respect the more compatible prototypes: They contain the correct number of parameters in a compatible order. However, some of the parameters do not have the same types yet: the strings are kept here in PUNICODE_STRINGS, while on Windows they are passed via an undocumented DSTRING struct, and the FMIFS callback is instead a MESSAGE struct/class on Windows. Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used in the corresponding FMIFS.DLL functions. One thing to notice is that the U*.DLL!Format() (and the Ex) functions support a BOOLEAN (a flag resp.) for telling that a backwards-compatible FS version should be used instead of the (default) latest FS version. This is used e.g. by the FAT FS, where by default FAT32 is selected (depending also on other constraints like, the disk and the partition sizes), unless that bit is set in which case, FAT16 (or 12) is used.
2020-11-22 04:35:37 +00:00
// Success = FALSE;
// Callback(DONE, 0, &Success);
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
return STATUS_NOT_SUPPORTED;
}
[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions. [AUTOCHK] Add also support for scanning FATX volumes. The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the U*.DLL user-mode FS library dlls are different (and have different prototypes) than the similarly-named functions exported by FMIFS.DLL . In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()" in our U*.DLL libraries actually correspond more, from their arguments, to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their *Ex() counterparts instead take most of the parameters through a structure passed by pointer. On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these *Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx() call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls U*.DLL!FormatEx() (that we do not implement yet either) !! To improve that, refactor the calls to these U*.DLL functions so as to respect the more compatible prototypes: They contain the correct number of parameters in a compatible order. However, some of the parameters do not have the same types yet: the strings are kept here in PUNICODE_STRINGS, while on Windows they are passed via an undocumented DSTRING struct, and the FMIFS callback is instead a MESSAGE struct/class on Windows. Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used in the corresponding FMIFS.DLL functions. One thing to notice is that the U*.DLL!Format() (and the Ex) functions support a BOOLEAN (a flag resp.) for telling that a backwards-compatible FS version should be used instead of the (default) latest FS version. This is used e.g. by the FAT FS, where by default FAT32 is selected (depending also on other constraints like, the disk and the partition sizes), unless that bit is set in which case, FAT16 (or 12) is used.
2020-11-22 04:35:37 +00:00
Status = STATUS_SUCCESS;
Success = FileSystem->ChkdskFunc(DriveRoot,
Callback,
FixErrors,
Verbose,
CheckOnlyIfDirty,
ScanDrive,
NULL,
NULL,
NULL,
NULL,
(PULONG)&Status);
if (!Success)
DPRINT1("ChkdskFunc() failed with Status 0x%lx\n", Status);
// Callback(DONE, 0, &Success);
return Status;
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
}
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
ChkdskFileSystem(
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
_In_ PCWSTR DriveRoot,
_In_ PCWSTR FileSystemName,
_In_ BOOLEAN FixErrors,
_In_ BOOLEAN Verbose,
_In_ BOOLEAN CheckOnlyIfDirty,
_In_ BOOLEAN ScanDrive,
_In_opt_ PFMIFSCALLBACK Callback)
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
{
UNICODE_STRING DriveRootU;
RtlInitUnicodeString(&DriveRootU, DriveRoot);
return ChkdskFileSystem_UStr(&DriveRootU,
FileSystemName,
FixErrors,
Verbose,
CheckOnlyIfDirty,
ScanDrive,
Callback);
}
/** FormatEx() **/
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
FormatFileSystem_UStr(
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
_In_ PUNICODE_STRING DriveRoot,
_In_ PCWSTR FileSystemName,
_In_ FMIFS_MEDIA_FLAG MediaFlag,
_In_opt_ PUNICODE_STRING Label,
_In_ BOOLEAN QuickFormat,
_In_ ULONG ClusterSize,
_In_opt_ PFMIFSCALLBACK Callback)
[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib. - Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem. - The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP. - Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list. - Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...). svn path=/branches/setup_improvements/; revision=74572 svn path=/branches/setup_improvements/; revision=74573
2017-05-17 23:31:52 +00:00
{
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
PFILE_SYSTEM FileSystem;
[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions. [AUTOCHK] Add also support for scanning FATX volumes. The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the U*.DLL user-mode FS library dlls are different (and have different prototypes) than the similarly-named functions exported by FMIFS.DLL . In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()" in our U*.DLL libraries actually correspond more, from their arguments, to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their *Ex() counterparts instead take most of the parameters through a structure passed by pointer. On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these *Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx() call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls U*.DLL!FormatEx() (that we do not implement yet either) !! To improve that, refactor the calls to these U*.DLL functions so as to respect the more compatible prototypes: They contain the correct number of parameters in a compatible order. However, some of the parameters do not have the same types yet: the strings are kept here in PUNICODE_STRINGS, while on Windows they are passed via an undocumented DSTRING struct, and the FMIFS callback is instead a MESSAGE struct/class on Windows. Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used in the corresponding FMIFS.DLL functions. One thing to notice is that the U*.DLL!Format() (and the Ex) functions support a BOOLEAN (a flag resp.) for telling that a backwards-compatible FS version should be used instead of the (default) latest FS version. This is used e.g. by the FAT FS, where by default FAT32 is selected (depending also on other constraints like, the disk and the partition sizes), unless that bit is set in which case, FAT16 (or 12) is used.
2020-11-22 04:35:37 +00:00
BOOLEAN Success;
BOOLEAN BackwardCompatible = FALSE; // Default to latest FS versions.
MEDIA_TYPE MediaType;
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
FileSystem = GetFileSystemByName(FileSystemName);
if (!FileSystem || !FileSystem->FormatFunc)
[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib. - Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem. - The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP. - Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list. - Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...). svn path=/branches/setup_improvements/; revision=74572 svn path=/branches/setup_improvements/; revision=74573
2017-05-17 23:31:52 +00:00
{
[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions. [AUTOCHK] Add also support for scanning FATX volumes. The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the U*.DLL user-mode FS library dlls are different (and have different prototypes) than the similarly-named functions exported by FMIFS.DLL . In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()" in our U*.DLL libraries actually correspond more, from their arguments, to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their *Ex() counterparts instead take most of the parameters through a structure passed by pointer. On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these *Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx() call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls U*.DLL!FormatEx() (that we do not implement yet either) !! To improve that, refactor the calls to these U*.DLL functions so as to respect the more compatible prototypes: They contain the correct number of parameters in a compatible order. However, some of the parameters do not have the same types yet: the strings are kept here in PUNICODE_STRINGS, while on Windows they are passed via an undocumented DSTRING struct, and the FMIFS callback is instead a MESSAGE struct/class on Windows. Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used in the corresponding FMIFS.DLL functions. One thing to notice is that the U*.DLL!Format() (and the Ex) functions support a BOOLEAN (a flag resp.) for telling that a backwards-compatible FS version should be used instead of the (default) latest FS version. This is used e.g. by the FAT FS, where by default FAT32 is selected (depending also on other constraints like, the disk and the partition sizes), unless that bit is set in which case, FAT16 (or 12) is used.
2020-11-22 04:35:37 +00:00
// Success = FALSE;
// Callback(DONE, 0, &Success);
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
return STATUS_NOT_SUPPORTED;
[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib. - Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem. - The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP. - Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list. - Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...). svn path=/branches/setup_improvements/; revision=74572 svn path=/branches/setup_improvements/; revision=74573
2017-05-17 23:31:52 +00:00
}
[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions. [AUTOCHK] Add also support for scanning FATX volumes. The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the U*.DLL user-mode FS library dlls are different (and have different prototypes) than the similarly-named functions exported by FMIFS.DLL . In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()" in our U*.DLL libraries actually correspond more, from their arguments, to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their *Ex() counterparts instead take most of the parameters through a structure passed by pointer. On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these *Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx() call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls U*.DLL!FormatEx() (that we do not implement yet either) !! To improve that, refactor the calls to these U*.DLL functions so as to respect the more compatible prototypes: They contain the correct number of parameters in a compatible order. However, some of the parameters do not have the same types yet: the strings are kept here in PUNICODE_STRINGS, while on Windows they are passed via an undocumented DSTRING struct, and the FMIFS callback is instead a MESSAGE struct/class on Windows. Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used in the corresponding FMIFS.DLL functions. One thing to notice is that the U*.DLL!Format() (and the Ex) functions support a BOOLEAN (a flag resp.) for telling that a backwards-compatible FS version should be used instead of the (default) latest FS version. This is used e.g. by the FAT FS, where by default FAT32 is selected (depending also on other constraints like, the disk and the partition sizes), unless that bit is set in which case, FAT16 (or 12) is used.
2020-11-22 04:35:37 +00:00
/* Set the BackwardCompatible flag in case we format with older FAT12/16 */
[SETUPLIB][USETUP] FS utilities: Use the ISO C and C++ conformant name: _wcsicmp Stop using non-conforming wcsicmp. See also PR #6925 by Timo Kreuzer.
2024-06-26 11:46:48 +00:00
if (_wcsicmp(FileSystemName, L"FAT") == 0)
[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions. [AUTOCHK] Add also support for scanning FATX volumes. The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the U*.DLL user-mode FS library dlls are different (and have different prototypes) than the similarly-named functions exported by FMIFS.DLL . In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()" in our U*.DLL libraries actually correspond more, from their arguments, to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their *Ex() counterparts instead take most of the parameters through a structure passed by pointer. On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these *Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx() call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls U*.DLL!FormatEx() (that we do not implement yet either) !! To improve that, refactor the calls to these U*.DLL functions so as to respect the more compatible prototypes: They contain the correct number of parameters in a compatible order. However, some of the parameters do not have the same types yet: the strings are kept here in PUNICODE_STRINGS, while on Windows they are passed via an undocumented DSTRING struct, and the FMIFS callback is instead a MESSAGE struct/class on Windows. Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used in the corresponding FMIFS.DLL functions. One thing to notice is that the U*.DLL!Format() (and the Ex) functions support a BOOLEAN (a flag resp.) for telling that a backwards-compatible FS version should be used instead of the (default) latest FS version. This is used e.g. by the FAT FS, where by default FAT32 is selected (depending also on other constraints like, the disk and the partition sizes), unless that bit is set in which case, FAT16 (or 12) is used.
2020-11-22 04:35:37 +00:00
BackwardCompatible = TRUE;
[SETUPLIB][USETUP] FS utilities: Use the ISO C and C++ conformant name: _wcsicmp Stop using non-conforming wcsicmp. See also PR #6925 by Timo Kreuzer.
2024-06-26 11:46:48 +00:00
// else if (_wcsicmp(FileSystemName, L"FAT32") == 0)
[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions. [AUTOCHK] Add also support for scanning FATX volumes. The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the U*.DLL user-mode FS library dlls are different (and have different prototypes) than the similarly-named functions exported by FMIFS.DLL . In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()" in our U*.DLL libraries actually correspond more, from their arguments, to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their *Ex() counterparts instead take most of the parameters through a structure passed by pointer. On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these *Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx() call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls U*.DLL!FormatEx() (that we do not implement yet either) !! To improve that, refactor the calls to these U*.DLL functions so as to respect the more compatible prototypes: They contain the correct number of parameters in a compatible order. However, some of the parameters do not have the same types yet: the strings are kept here in PUNICODE_STRINGS, while on Windows they are passed via an undocumented DSTRING struct, and the FMIFS callback is instead a MESSAGE struct/class on Windows. Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used in the corresponding FMIFS.DLL functions. One thing to notice is that the U*.DLL!Format() (and the Ex) functions support a BOOLEAN (a flag resp.) for telling that a backwards-compatible FS version should be used instead of the (default) latest FS version. This is used e.g. by the FAT FS, where by default FAT32 is selected (depending also on other constraints like, the disk and the partition sizes), unless that bit is set in which case, FAT16 (or 12) is used.
2020-11-22 04:35:37 +00:00
// BackwardCompatible = FALSE;
/* Convert the FMIFS MediaFlag to a NT MediaType */
// FIXME: Actually covert all the possible flags.
switch (MediaFlag)
{
case FMIFS_FLOPPY:
MediaType = F5_320_1024; // FIXME: This is hardfixed!
break;
case FMIFS_REMOVABLE:
MediaType = RemovableMedia;
break;
case FMIFS_HARDDISK:
MediaType = FixedMedia;
break;
default:
DPRINT1("Unknown FMIFS MediaFlag %d, converting 1-to-1 to NT MediaType\n",
MediaFlag);
MediaType = (MEDIA_TYPE)MediaFlag;
break;
}
Success = FileSystem->FormatFunc(DriveRoot,
Callback,
QuickFormat,
BackwardCompatible,
MediaType,
Label,
ClusterSize);
if (!Success)
DPRINT1("FormatFunc() failed\n");
// Callback(DONE, 0, &Success);
return (Success ? STATUS_SUCCESS : STATUS_UNSUCCESSFUL);
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
}
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
FormatFileSystem(
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
_In_ PCWSTR DriveRoot,
_In_ PCWSTR FileSystemName,
_In_ FMIFS_MEDIA_FLAG MediaFlag,
_In_opt_ PCWSTR Label,
_In_ BOOLEAN QuickFormat,
_In_ ULONG ClusterSize,
_In_opt_ PFMIFSCALLBACK Callback)
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
{
UNICODE_STRING DriveRootU;
UNICODE_STRING LabelU;
RtlInitUnicodeString(&DriveRootU, DriveRoot);
RtlInitUnicodeString(&LabelU, Label);
return FormatFileSystem_UStr(&DriveRootU,
FileSystemName,
MediaFlag,
&LabelU,
QuickFormat,
ClusterSize,
Callback);
}
[SETUPLIB] Code re-organization in bootsup.c and fsutil.c. - Move the actual VBR bootcode installation helpers into fsutil.c (they depend on the selected filesystem). - Introduce InstallBootCodeToDisk() and InstallBootCodeToFile() and bootcode.c helpers, in order to replace the several functions that were duplicating the same code.
2020-10-17 18:29:47 +00:00
//
// Bootsector routines
//
NTSTATUS
[USETUP][SETUPLIB] Continue hiding the FAT32 format in the format list, but take it into account anyway later on. The formatter will select it anyway as soon as the partition size permits it. We make it available internally however so as to "emulate" FMIFS functionality. Now rely on the partition filesystem for InstallVBRToPartition() instead of the unreliable and deprecated partition type.
2020-10-19 21:49:26 +00:00
InstallFatBootCode(
[SETUPLIB] Code re-organization in bootsup.c and fsutil.c. - Move the actual VBR bootcode installation helpers into fsutil.c (they depend on the selected filesystem). - Introduce InstallBootCodeToDisk() and InstallBootCodeToFile() and bootcode.c helpers, in order to replace the several functions that were duplicating the same code.
2020-10-17 18:29:47 +00:00
IN PCWSTR SrcPath, // FAT12/16 bootsector source file (on the installation medium)
IN HANDLE DstPath, // Where to save the bootsector built from the source + partition information
IN HANDLE RootPartition) // Partition holding the (old) FAT12/16 information
{
NTSTATUS Status;
UNICODE_STRING Name;
IO_STATUS_BLOCK IoStatusBlock;
LARGE_INTEGER FileOffset;
BOOTCODE OrigBootSector = {0};
BOOTCODE NewBootSector = {0};
/* Allocate and read the current original partition bootsector */
Status = ReadBootCodeByHandle(&OrigBootSector,
RootPartition,
FAT_BOOTSECTOR_SIZE);
if (!NT_SUCCESS(Status))
return Status;
/* Allocate and read the new bootsector from SrcPath */
RtlInitUnicodeString(&Name, SrcPath);
Status = ReadBootCodeFromFile(&NewBootSector,
&Name,
FAT_BOOTSECTOR_SIZE);
if (!NT_SUCCESS(Status))
{
FreeBootCode(&OrigBootSector);
return Status;
}
/* Adjust the bootsector (copy a part of the FAT12/16 BPB) */
RtlCopyMemory(&((PFAT_BOOTSECTOR)NewBootSector.BootCode)->OemName,
&((PFAT_BOOTSECTOR)OrigBootSector.BootCode)->OemName,
FIELD_OFFSET(FAT_BOOTSECTOR, BootCodeAndData) -
FIELD_OFFSET(FAT_BOOTSECTOR, OemName));
/* Free the original bootsector */
FreeBootCode(&OrigBootSector);
/* Write the new bootsector to DstPath */
FileOffset.QuadPart = 0ULL;
Status = NtWriteFile(DstPath,
NULL,
NULL,
NULL,
&IoStatusBlock,
NewBootSector.BootCode,
NewBootSector.Length,
&FileOffset,
NULL);
/* Free the new bootsector */
FreeBootCode(&NewBootSector);
return Status;
}
NTSTATUS
InstallFat32BootCode(
IN PCWSTR SrcPath, // FAT32 bootsector source file (on the installation medium)
IN HANDLE DstPath, // Where to save the bootsector built from the source + partition information
IN HANDLE RootPartition) // Partition holding the (old) FAT32 information
{
NTSTATUS Status;
UNICODE_STRING Name;
IO_STATUS_BLOCK IoStatusBlock;
LARGE_INTEGER FileOffset;
USHORT BackupBootSector = 0;
BOOTCODE OrigBootSector = {0};
BOOTCODE NewBootSector = {0};
/* Allocate and read the current original partition bootsector */
Status = ReadBootCodeByHandle(&OrigBootSector,
RootPartition,
FAT32_BOOTSECTOR_SIZE);
if (!NT_SUCCESS(Status))
return Status;
/* Allocate and read the new bootsector (2 sectors) from SrcPath */
RtlInitUnicodeString(&Name, SrcPath);
Status = ReadBootCodeFromFile(&NewBootSector,
&Name,
2 * FAT32_BOOTSECTOR_SIZE);
if (!NT_SUCCESS(Status))
{
FreeBootCode(&OrigBootSector);
return Status;
}
/* Adjust the bootsector (copy a part of the FAT32 BPB) */
RtlCopyMemory(&((PFAT32_BOOTSECTOR)NewBootSector.BootCode)->OemName,
&((PFAT32_BOOTSECTOR)OrigBootSector.BootCode)->OemName,
FIELD_OFFSET(FAT32_BOOTSECTOR, BootCodeAndData) -
FIELD_OFFSET(FAT32_BOOTSECTOR, OemName));
/*
* We know we copy the boot code to a file only when DstPath != RootPartition,
* otherwise the boot code is copied to the specified root partition.
*/
if (DstPath != RootPartition)
{
/* Copy to a file: Disable the backup bootsector */
((PFAT32_BOOTSECTOR)NewBootSector.BootCode)->BackupBootSector = 0;
}
else
{
/* Copy to a disk: Get the location of the backup bootsector */
BackupBootSector = ((PFAT32_BOOTSECTOR)OrigBootSector.BootCode)->BackupBootSector;
}
/* Free the original bootsector */
FreeBootCode(&OrigBootSector);
/* Write the first sector of the new bootcode to DstPath sector 0 */
FileOffset.QuadPart = 0ULL;
Status = NtWriteFile(DstPath,
NULL,
NULL,
NULL,
&IoStatusBlock,
NewBootSector.BootCode,
FAT32_BOOTSECTOR_SIZE,
&FileOffset,
NULL);
if (!NT_SUCCESS(Status))
{
DPRINT1("NtWriteFile() failed (Status %lx)\n", Status);
FreeBootCode(&NewBootSector);
return Status;
}
if (DstPath == RootPartition)
{
/* Copy to a disk: Write the backup bootsector */
if ((BackupBootSector != 0x0000) && (BackupBootSector != 0xFFFF))
{
FileOffset.QuadPart = (ULONGLONG)((ULONG)BackupBootSector * FAT32_BOOTSECTOR_SIZE);
Status = NtWriteFile(DstPath,
NULL,
NULL,
NULL,
&IoStatusBlock,
NewBootSector.BootCode,
FAT32_BOOTSECTOR_SIZE,
&FileOffset,
NULL);
if (!NT_SUCCESS(Status))
{
DPRINT1("NtWriteFile() failed (Status %lx)\n", Status);
FreeBootCode(&NewBootSector);
return Status;
}
}
}
/* Write the second sector of the new bootcode to boot disk sector 14 */
// FileOffset.QuadPart = (ULONGLONG)(14 * FAT32_BOOTSECTOR_SIZE);
FileOffset.QuadPart = 14 * FAT32_BOOTSECTOR_SIZE;
Status = NtWriteFile(DstPath, // or really RootPartition ???
NULL,
NULL,
NULL,
&IoStatusBlock,
((PUCHAR)NewBootSector.BootCode + FAT32_BOOTSECTOR_SIZE),
FAT32_BOOTSECTOR_SIZE,
&FileOffset,
NULL);
if (!NT_SUCCESS(Status))
{
DPRINT1("NtWriteFile() failed (Status %lx)\n", Status);
}
/* Free the new bootsector */
FreeBootCode(&NewBootSector);
return Status;
}
NTSTATUS
InstallBtrfsBootCode(
IN PCWSTR SrcPath, // BTRFS bootsector source file (on the installation medium)
IN HANDLE DstPath, // Where to save the bootsector built from the source + partition information
IN HANDLE RootPartition) // Partition holding the (old) BTRFS information
{
NTSTATUS Status;
NTSTATUS LockStatus;
UNICODE_STRING Name;
IO_STATUS_BLOCK IoStatusBlock;
LARGE_INTEGER FileOffset;
PARTITION_INFORMATION_EX PartInfo;
BOOTCODE NewBootSector = {0};
/* Allocate and read the new bootsector from SrcPath */
RtlInitUnicodeString(&Name, SrcPath);
Status = ReadBootCodeFromFile(&NewBootSector,
&Name,
BTRFS_BOOTSECTOR_SIZE);
if (!NT_SUCCESS(Status))
return Status;
/*
* The BTRFS driver requires the volume to be locked in order to modify
* the first sectors of the partition, even though they are outside the
* file-system space / in the reserved area (they are situated before
* the super-block at 0x1000) and is in principle allowed by the NT
* storage stack.
* So we lock here in order to write the bootsector at sector 0.
* If locking fails, we ignore and continue nonetheless.
*/
LockStatus = NtFsControlFile(DstPath,
NULL,
NULL,
NULL,
&IoStatusBlock,
FSCTL_LOCK_VOLUME,
NULL,
0,
NULL,
0);
if (!NT_SUCCESS(LockStatus))
{
DPRINT1("WARNING: Failed to lock BTRFS volume for writing bootsector! Operations may fail! (Status 0x%lx)\n", LockStatus);
}
/* Obtain partition info and write it to the bootsector */
Status = NtDeviceIoControlFile(RootPartition,
NULL,
NULL,
NULL,
&IoStatusBlock,
IOCTL_DISK_GET_PARTITION_INFO_EX,
NULL,
0,
&PartInfo,
sizeof(PartInfo));
if (!NT_SUCCESS(Status))
{
DPRINT1("IOCTL_DISK_GET_PARTITION_INFO_EX failed (Status %lx)\n", Status);
goto Quit;
}
/* Write new bootsector to RootPath */
((PBTRFS_BOOTSECTOR)NewBootSector.BootCode)->PartitionStartLBA =
PartInfo.StartingOffset.QuadPart / SECTORSIZE;
/* Write sector 0 */
FileOffset.QuadPart = 0ULL;
Status = NtWriteFile(DstPath,
NULL,
NULL,
NULL,
&IoStatusBlock,
NewBootSector.BootCode,
NewBootSector.Length,
&FileOffset,
NULL);
if (!NT_SUCCESS(Status))
{
DPRINT1("NtWriteFile() failed (Status %lx)\n", Status);
goto Quit;
}
Quit:
/* Unlock the volume */
LockStatus = NtFsControlFile(DstPath,
NULL,
NULL,
NULL,
&IoStatusBlock,
FSCTL_UNLOCK_VOLUME,
NULL,
0,
NULL,
0);
if (!NT_SUCCESS(LockStatus))
{
DPRINT1("Failed to unlock BTRFS volume (Status 0x%lx)\n", LockStatus);
}
/* Free the new bootsector */
FreeBootCode(&NewBootSector);
return Status;
}
[SETUPLIB] Add NTFS boot support. (#3778)
2022-10-19 00:02:24 +00:00
NTSTATUS
InstallNtfsBootCode(
IN PCWSTR SrcPath, // NTFS bootsector source file (on the installation medium)
IN HANDLE DstPath, // Where to save the bootsector built from the source + partition information
IN HANDLE RootPartition) // Partition holding the (old) NTFS information
{
NTSTATUS Status;
UNICODE_STRING Name;
IO_STATUS_BLOCK IoStatusBlock;
LARGE_INTEGER FileOffset;
BOOTCODE OrigBootSector = {0};
BOOTCODE NewBootSector = {0};
/* Allocate and read the current original partition bootsector */
Status = ReadBootCodeByHandle(&OrigBootSector, RootPartition, NTFS_BOOTSECTOR_SIZE);
if (!NT_SUCCESS(Status))
{
DPRINT1("InstallNtfsBootCode: Status %lx\n", Status);
return Status;
}
/* Allocate and read the new bootsector (16 sectors) from SrcPath */
RtlInitUnicodeString(&Name, SrcPath);
Status = ReadBootCodeFromFile(&NewBootSector, &Name, NTFS_BOOTSECTOR_SIZE);
if (!NT_SUCCESS(Status))
{
DPRINT1("InstallNtfsBootCode: Status %lx\n", Status);
FreeBootCode(&OrigBootSector);
return Status;
}
/* Adjust the bootsector (copy a part of the NTFS BPB) */
RtlCopyMemory(&((PNTFS_BOOTSECTOR)NewBootSector.BootCode)->OEMID,
&((PNTFS_BOOTSECTOR)OrigBootSector.BootCode)->OEMID,
FIELD_OFFSET(NTFS_BOOTSECTOR, BootStrap) - FIELD_OFFSET(NTFS_BOOTSECTOR, OEMID));
/* Write sector 0 */
FileOffset.QuadPart = 0ULL;
Status = NtWriteFile(DstPath,
NULL,
NULL,
NULL,
&IoStatusBlock,
NewBootSector.BootCode,
NewBootSector.Length,
&FileOffset,
NULL);
if (!NT_SUCCESS(Status))
{
DPRINT1("NtWriteFile() failed (Status %lx)\n", Status);
goto Quit;
}
Quit:
/* Free the new bootsector */
FreeBootCode(&NewBootSector);
return Status;
}
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
//
// Formatting routines
//
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
ChkdskVolume(
_In_ PVOLINFO Volume,
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
_In_ BOOLEAN FixErrors,
_In_ BOOLEAN Verbose,
_In_ BOOLEAN CheckOnlyIfDirty,
_In_ BOOLEAN ScanDrive,
_In_opt_ PFMIFSCALLBACK Callback)
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
{
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
/* Do not check a volume with an unknown file system */
if (!*Volume->FileSystem)
return STATUS_UNRECOGNIZED_VOLUME;
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
/* Check the volume */
DPRINT("Volume->DeviceName: %S\n", Volume->DeviceName);
return ChkdskFileSystem(Volume->DeviceName,
Volume->FileSystem,
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
FixErrors,
Verbose,
CheckOnlyIfDirty,
ScanDrive,
Callback);
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
}
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
ChkdskPartition(
_In_ PPARTENTRY PartEntry,
_In_ BOOLEAN FixErrors,
_In_ BOOLEAN Verbose,
_In_ BOOLEAN CheckOnlyIfDirty,
_In_ BOOLEAN ScanDrive,
_In_opt_ PFMIFSCALLBACK Callback)
{
ASSERT(PartEntry->IsPartitioned && PartEntry->PartitionNumber != 0);
ASSERT(PartEntry->Volume);
// if (!PartEntry->Volume) { check_raw_sectors(); } else { check_FS(); }
/* Check the associated volume */
return ChkdskVolume(&PartEntry->Volume->Info,
FixErrors,
Verbose,
CheckOnlyIfDirty,
ScanDrive,
Callback);
}
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
FormatVolume(
_In_ PVOLINFO Volume,
_In_ PCWSTR FileSystemName,
_In_ FMIFS_MEDIA_FLAG MediaFlag,
_In_opt_ PCWSTR Label,
_In_ BOOLEAN QuickFormat,
_In_ ULONG ClusterSize,
_In_opt_ PFMIFSCALLBACK Callback)
{
NTSTATUS Status;
if (!FileSystemName || !*FileSystemName)
{
DPRINT1("No file system specified\n");
return STATUS_UNRECOGNIZED_VOLUME;
}
/* Format the volume */
DPRINT("Volume->DeviceName: %S\n", Volume->DeviceName);
Status = FormatFileSystem(Volume->DeviceName,
FileSystemName,
MediaFlag,
Label,
QuickFormat,
ClusterSize,
Callback);
if (!NT_SUCCESS(Status))
return Status;
/* Set the new volume's file system and label */
RtlStringCbCopyW(Volume->FileSystem, sizeof(Volume->FileSystem), FileSystemName);
if (!Label) Label = L"";
RtlStringCbCopyW(Volume->VolumeLabel, sizeof(Volume->VolumeLabel), Label);
return STATUS_SUCCESS;
}
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
FormatPartition(
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
_In_ PPARTENTRY PartEntry,
_In_ PCWSTR FileSystemName,
_In_ FMIFS_MEDIA_FLAG MediaFlag,
_In_opt_ PCWSTR Label,
_In_ BOOLEAN QuickFormat,
_In_ ULONG ClusterSize,
_In_opt_ PFMIFSCALLBACK Callback)
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
{
NTSTATUS Status;
PDISKENTRY DiskEntry = PartEntry->DiskEntry;
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
UCHAR PartitionType;
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
ASSERT(PartEntry->IsPartitioned && PartEntry->PartitionNumber != 0);
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
if (!FileSystemName || !*FileSystemName)
{
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
DPRINT1("No file system specified\n");
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
return STATUS_UNRECOGNIZED_VOLUME;
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
}
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
/*
* Prepare the partition for formatting (for MBR disks, reset the
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
* partition type), and adjust the file system name in case of FAT
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
* vs. FAT32, depending on the geometry of the partition.
*/
// FIXME: Do this only if QuickFormat == FALSE? What about FAT handling?
/*
* Retrieve a partition type as a hint only. It will be used to determine
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
* whether to actually use FAT12/16 or FAT32 file system, depending on the
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
* geometry of the partition. If the partition resides on an MBR disk,
* the partition style will be reset to this value as well, unless the
* partition is OEM.
*/
[SETUPLIB] Make InferFileSystem() compatible for both MBR and GPT disks. Simplify the FSREC interface a bit. 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).
2020-11-24 00:49:41 +00:00
PartitionType = FileSystemToMBRPartitionType(FileSystemName,
PartEntry->StartSector.QuadPart,
PartEntry->SectorCount.QuadPart);
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
if (PartitionType == PARTITION_ENTRY_UNUSED)
[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib. - Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem. - The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP. - Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list. - Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...). svn path=/branches/setup_improvements/; revision=74572 svn path=/branches/setup_improvements/; revision=74573
2017-05-17 23:31:52 +00:00
{
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
/* Unknown file system */
DPRINT1("Unknown file system '%S'\n", FileSystemName);
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
return STATUS_UNRECOGNIZED_VOLUME;
[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib. - Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem. - The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP. - Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list. - Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...). svn path=/branches/setup_improvements/; revision=74572 svn path=/branches/setup_improvements/; revision=74573
2017-05-17 23:31:52 +00:00
}
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
/* Reset the MBR partition type, unless this is an OEM partition */
if (DiskEntry->DiskStyle == PARTITION_STYLE_MBR)
{
if (!IsOEMPartition(PartEntry->PartitionType))
SetMBRPartitionType(PartEntry, PartitionType);
}
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. 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.
2019-02-24 16:52:33 +00:00
[USETUP][SETUPLIB] Continue hiding the FAT32 format in the format list, but take it into account anyway later on. The formatter will select it anyway as soon as the partition size permits it. We make it available internally however so as to "emulate" FMIFS functionality. Now rely on the partition filesystem for InstallVBRToPartition() instead of the unreliable and deprecated partition type.
2020-10-19 21:49:26 +00:00
/*
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
* Adjust the file system name in case of FAT vs. FAT32, according to
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
* the type of partition returned by FileSystemToMBRPartitionType().
[USETUP][SETUPLIB] Continue hiding the FAT32 format in the format list, but take it into account anyway later on. The formatter will select it anyway as soon as the partition size permits it. We make it available internally however so as to "emulate" FMIFS functionality. Now rely on the partition filesystem for InstallVBRToPartition() instead of the unreliable and deprecated partition type.
2020-10-19 21:49:26 +00:00
*/
[SETUPLIB][USETUP] FS utilities: Use the ISO C and C++ conformant name: _wcsicmp Stop using non-conforming wcsicmp. See also PR #6925 by Timo Kreuzer.
2024-06-26 11:46:48 +00:00
if (_wcsicmp(FileSystemName, L"FAT") == 0)
[USETUP][SETUPLIB] Continue hiding the FAT32 format in the format list, but take it into account anyway later on. The formatter will select it anyway as soon as the partition size permits it. We make it available internally however so as to "emulate" FMIFS functionality. Now rely on the partition filesystem for InstallVBRToPartition() instead of the unreliable and deprecated partition type.
2020-10-19 21:49:26 +00:00
{
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
if ((PartitionType == PARTITION_FAT32) ||
(PartitionType == PARTITION_FAT32_XINT13))
[USETUP][SETUPLIB] Continue hiding the FAT32 format in the format list, but take it into account anyway later on. The formatter will select it anyway as soon as the partition size permits it. We make it available internally however so as to "emulate" FMIFS functionality. Now rely on the partition filesystem for InstallVBRToPartition() instead of the unreliable and deprecated partition type.
2020-10-19 21:49:26 +00:00
{
FileSystemName = L"FAT32";
}
}
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
/* Commit the partition changes to the disk */
Status = WritePartitions(DiskEntry);
if (!NT_SUCCESS(Status))
{
DPRINT1("WritePartitions(disk %lu) failed, Status 0x%08lx\n",
DiskEntry->DiskNumber, Status);
return STATUS_PARTITION_FAILURE;
}
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
/* We must have an associated volume now */
ASSERT(PartEntry->Volume);
/* Format the associated volume */
Status = FormatVolume(&PartEntry->Volume->Info,
FileSystemName,
MediaFlag,
Label,
QuickFormat,
ClusterSize,
Callback);
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
if (!NT_SUCCESS(Status))
return Status;
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
PartEntry->Volume->FormatState = Formatted;
PartEntry->Volume->New = FALSE;
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers 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).
2020-11-24 01:26:52 +00:00
return STATUS_SUCCESS;
[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib. - Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem. - The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP. - Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list. - Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...). svn path=/branches/setup_improvements/; revision=74572 svn path=/branches/setup_improvements/; revision=74573
2017-05-17 23:31:52 +00:00
}
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
//
// FileSystem Volume Operations Queue
//
static FSVOL_OP
DoFormatting(
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
_In_ PVOLENTRY Volume,
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
_In_opt_ PVOID Context,
_In_opt_ PFSVOL_CALLBACK FsVolCallback)
{
FSVOL_OP Result;
NTSTATUS Status = STATUS_SUCCESS;
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
PPARTENTRY PartEntry;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
FORMAT_VOLUME_INFO FmtInfo = {0};
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
PartEntry = Volume->PartEntry;
ASSERT(PartEntry && (PartEntry->Volume == Volume));
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
FmtInfo.Volume = Volume;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
RetryFormat:
Result = FsVolCallback(Context,
FSVOLNOTIFY_STARTFORMAT,
(ULONG_PTR)&FmtInfo,
FSVOL_FORMAT);
if (Result != FSVOL_DOIT)
goto EndFormat;
ASSERT(FmtInfo.FileSystemName && *FmtInfo.FileSystemName);
/* Format the partition */
Status = FormatPartition(PartEntry,
FmtInfo.FileSystemName,
FmtInfo.MediaFlag,
FmtInfo.Label,
FmtInfo.QuickFormat,
FmtInfo.ClusterSize,
FmtInfo.Callback);
if (!NT_SUCCESS(Status))
{
// FmtInfo.NtPathPartition = PathBuffer;
FmtInfo.ErrorStatus = Status;
Result = FsVolCallback(Context,
FSVOLNOTIFY_FORMATERROR,
(ULONG_PTR)&FmtInfo,
0);
if (Result == FSVOL_RETRY)
goto RetryFormat;
// else if (Result == FSVOL_ABORT || Result == FSVOL_SKIP), stop.
}
EndFormat:
/* This notification is always sent, even in case of error or abort */
FmtInfo.ErrorStatus = Status;
FsVolCallback(Context,
FSVOLNOTIFY_ENDFORMAT,
(ULONG_PTR)&FmtInfo,
0);
return Result;
}
static FSVOL_OP
DoChecking(
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
_In_ PVOLENTRY Volume,
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
_In_opt_ PVOID Context,
_In_opt_ PFSVOL_CALLBACK FsVolCallback)
{
FSVOL_OP Result;
NTSTATUS Status = STATUS_SUCCESS;
CHECK_VOLUME_INFO ChkInfo = {0};
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
ASSERT(*Volume->Info.FileSystem);
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
ChkInfo.Volume = Volume;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
RetryCheck:
Result = FsVolCallback(Context,
FSVOLNOTIFY_STARTCHECK,
(ULONG_PTR)&ChkInfo,
FSVOL_CHECK);
if (Result != FSVOL_DOIT)
goto EndCheck;
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
/* Check the volume */
Status = ChkdskVolume(&Volume->Info,
ChkInfo.FixErrors,
ChkInfo.Verbose,
ChkInfo.CheckOnlyIfDirty,
ChkInfo.ScanDrive,
ChkInfo.Callback);
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
/* If volume checking succeeded, or if it is not supported
* with the current file system, disable checks on the volume */
if (NT_SUCCESS(Status) || (Status == STATUS_NOT_SUPPORTED))
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
Volume->NeedsCheck = FALSE;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
if (!NT_SUCCESS(Status))
{
// ChkInfo.NtPathPartition = PathBuffer;
ChkInfo.ErrorStatus = Status;
Result = FsVolCallback(Context,
FSVOLNOTIFY_CHECKERROR,
(ULONG_PTR)&ChkInfo,
0);
if (Result == FSVOL_RETRY)
goto RetryCheck;
// else if (Result == FSVOL_ABORT || Result == FSVOL_SKIP), stop.
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
// Volume->NeedsCheck = FALSE;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
}
EndCheck:
/* This notification is always sent, even in case of error or abort */
ChkInfo.ErrorStatus = Status;
FsVolCallback(Context,
FSVOLNOTIFY_ENDCHECK,
(ULONG_PTR)&ChkInfo,
0);
return Result;
}
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
static
PVOLENTRY
GetNextUnformattedVolume(
_In_ PPARTLIST List,
_In_opt_ PVOLENTRY Volume)
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
{
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
PLIST_ENTRY Entry;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
for (;;)
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
{
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
/* If we have a current volume, get the next one, otherwise get the first */
Entry = (Volume ? &Volume->ListEntry : &List->VolumesList);
Entry = Entry->Flink;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
if (Entry == &List->VolumesList)
return NULL;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
Volume = CONTAINING_RECORD(Entry, VOLENTRY, ListEntry);
if (Volume->New && (Volume->FormatState == Unformatted))
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
{
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
/* Found a candidate, return it */
return Volume;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
}
}
}
BOOLEAN
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
FsVolCommitOpsQueue(
_In_ PPARTLIST PartitionList,
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
_In_ PVOLENTRY SystemVolume,
_In_ PVOLENTRY InstallVolume,
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
_In_opt_ PFSVOL_CALLBACK FsVolCallback,
_In_opt_ PVOID Context)
{
BOOLEAN Success = TRUE; // Suppose success originally.
FSVOL_OP Result;
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
PLIST_ENTRY Entry;
PVOLENTRY Volume;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
/* Machine state for the format step */
typedef enum _FORMATMACHINESTATE
{
Start,
FormatSystemVolume,
FormatInstallVolume,
FormatOtherVolume,
FormatDone
} FORMATMACHINESTATE;
FORMATMACHINESTATE FormatState, OldFormatState;
static const PCSTR FormatStateNames[] = {
"Start",
"FormatSystemVolume",
"FormatInstallVolume",
"FormatOtherVolume",
"FormatDone"
};
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
ASSERT(PartitionList && SystemVolume && InstallVolume);
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
/* Commit all partition changes to all the disks */
if (!WritePartitionsToDisk(PartitionList))
{
DPRINT("WritePartitionsToDisk() failed\n");
/* Result = */ FsVolCallback(Context,
FSVOLNOTIFY_PARTITIONERROR,
STATUS_PARTITION_FAILURE, // FIXME
0);
return FALSE;
}
//
// FIXME: Should we do the following here, or in the caller?
//
/*
* In all cases, whether or not we are going to perform a formatting,
* we must perform a file system check of both the system and the
* installation volumes.
*/
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
SystemVolume->NeedsCheck = TRUE;
InstallVolume->NeedsCheck = TRUE;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
Result = FsVolCallback(Context,
FSVOLNOTIFY_STARTQUEUE,
0, 0);
if (Result == FSVOL_ABORT)
return FALSE;
/*
* Commit the Format queue
*/
Result = FsVolCallback(Context,
FSVOLNOTIFY_STARTSUBQUEUE,
FSVOL_FORMAT,
0);
if (Result == FSVOL_ABORT)
return FALSE;
/** HACK!! **/
if (Result == FSVOL_SKIP)
goto StartCheckQueue;
/** END HACK!! **/
/* Reset the formatter machine state */
FormatState = Start;
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
Volume = NULL;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
NextFormat:
OldFormatState = FormatState;
switch (FormatState)
{
case Start:
{
/*
* We start by formatting the system volume in case it is new
* (it didn't exist before) and is not the same as the installation
* volume. Otherwise we just require a file system check on it,
* and start by formatting the installation volume instead.
*/
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
if (SystemVolume != InstallVolume)
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
{
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
Volume = SystemVolume;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
if (Volume->FormatState == Unformatted)
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
{
// TODO: Should we let the user use a custom file system,
// or should we always use FAT(32) for it?
// For "compatibility", FAT(32) would be best indeed.
FormatState = FormatSystemVolume;
DPRINT1("FormatState: %s --> %s\n",
FormatStateNames[OldFormatState], FormatStateNames[FormatState]);
break;
}
/* The system volume is separate, so it had better be formatted! */
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
ASSERT(Volume->FormatState == Formatted);
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
/* Require a file system check on the system volume too */
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
Volume->NeedsCheck = TRUE;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
}
__fallthrough;
}
case FormatSystemVolume:
{
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
Volume = InstallVolume;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
FormatState = FormatInstallVolume;
DPRINT1("FormatState: %s --> %s\n",
FormatStateNames[OldFormatState], FormatStateNames[FormatState]);
break;
}
case FormatInstallVolume:
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
/* Restart volume enumeration */
Volume = NULL;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
case FormatOtherVolume:
{
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
Volume = GetNextUnformattedVolume(PartitionList, Volume);
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
FormatState = (Volume ? FormatOtherVolume : FormatDone);
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
DPRINT1("FormatState: %s --> %s\n",
FormatStateNames[OldFormatState], FormatStateNames[FormatState]);
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
if (Volume)
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
break;
__fallthrough;
}
case FormatDone:
{
DPRINT1("FormatState: FormatDone\n");
Success = TRUE;
goto EndFormat;
}
DEFAULT_UNREACHABLE;
}
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
Result = DoFormatting(Volume, Context, FsVolCallback);
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
if (Result == FSVOL_ABORT)
{
Success = FALSE;
goto Quit;
}
/* Schedule a check for this volume */
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
Volume->NeedsCheck = TRUE;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
/* Go to the next volume to be formatted */
goto NextFormat;
EndFormat:
FsVolCallback(Context,
FSVOLNOTIFY_ENDSUBQUEUE,
FSVOL_FORMAT,
0);
/*
* Commit the CheckFS queue
*/
StartCheckQueue:
Result = FsVolCallback(Context,
FSVOLNOTIFY_STARTSUBQUEUE,
FSVOL_CHECK,
0);
if (Result == FSVOL_ABORT)
return FALSE;
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
/* Loop through each unchecked volume and do the check */
for (Entry = PartitionList->VolumesList.Flink;
Entry != &PartitionList->VolumesList;
Entry = Entry->Flink)
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
{
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
Volume = CONTAINING_RECORD(Entry, VOLENTRY, ListEntry);
if (!Volume->NeedsCheck)
continue;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
/* Found a candidate */
ASSERT(Volume->FormatState == Formatted);
Result = DoChecking(Volume, Context, FsVolCallback);
if (Result == FSVOL_ABORT)
{
Success = FALSE;
goto Quit;
}
/* Go to the next volume to be checked */
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
}
[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258) 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.
2024-05-18 21:09:16 +00:00
Success = TRUE;
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) 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.
2020-11-23 03:38:51 +00:00
FsVolCallback(Context,
FSVOLNOTIFY_ENDSUBQUEUE,
FSVOL_CHECK,
0);
Quit:
/* All the queues have been committed */
FsVolCallback(Context,
FSVOLNOTIFY_ENDQUEUE,
Success,
0);
return Success;
}
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark old times. svn path=/branches/setup_improvements/; revision=74570 svn path=/branches/setup_improvements/; revision=74659
2017-05-17 23:37:41 +00:00
/* EOF */
Reference in a new issue Copy permalink