reactos/dll/win32/fmifs/format.c

129 lines
3.3 KiB
C
Raw Normal View History

/*
* COPYRIGHT: See COPYING in the top level directory
* PROJECT: File Management IFS Utility functions
* FILE: reactos/dll/win32/fmifs/format.c
* PURPOSE: Volume format
*
* PROGRAMMERS: Emanuele Aliberti
* Herv<EFBFBD> Poussineau (hpoussin@reactos.org)
*/
#include "precomp.h"
#define NDEBUG
#include <debug.h>
/* FMIFS.6 */
VOID NTAPI
Format(
IN PWCHAR DriveRoot,
IN FMIFS_MEDIA_FLAG MediaFlag,
IN PWCHAR Format,
IN PWCHAR Label,
IN BOOLEAN QuickFormat,
IN PFMIFSCALLBACK Callback)
{
FormatEx(DriveRoot,
MediaFlag,
Format,
Label,
QuickFormat,
0,
Callback);
}
/* FMIFS.7 */
VOID
NTAPI
FormatEx(
IN PWCHAR DriveRoot,
IN FMIFS_MEDIA_FLAG MediaFlag,
IN PWCHAR Format,
IN PWCHAR Label,
IN BOOLEAN QuickFormat,
IN ULONG ClusterSize,
IN PFMIFSCALLBACK Callback)
{
PIFS_PROVIDER Provider;
UNICODE_STRING usDriveRoot;
UNICODE_STRING usLabel;
[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 = FALSE;
BOOLEAN BackwardCompatible = FALSE; // Default to latest FS versions.
MEDIA_TYPE MediaType;
WCHAR VolumeName[MAX_PATH];
//CURDIR CurDir;
[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
//
// TODO: Convert filesystem Format into ULIB format string.
//
Provider = GetProvider(Format);
if (!Provider)
{
/* Unknown file system */
[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
Callback(DONE, 0, &Success);
return;
}
#if 1
DPRINT1("Warning: use GetVolumeNameForVolumeMountPointW() instead!\n");
swprintf(VolumeName, L"\\??\\%c:", towupper(DriveRoot[0]));
RtlCreateUnicodeString(&usDriveRoot, VolumeName);
/* Code disabled as long as our storage stack doesn't understand IOCTL_MOUNTDEV_QUERY_DEVICE_NAME */
#else
[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
if (!GetVolumeNameForVolumeMountPointW(DriveRoot, VolumeName, RTL_NUMBER_OF(VolumeName)) ||
!RtlDosPathNameToNtPathName_U(VolumeName, &usDriveRoot, NULL, &CurDir))
{
[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
/* Report an error */
Callback(DONE, 0, &Success);
return;
}
#endif
RtlInitUnicodeString(&usLabel, Label);
[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 */
if (wcsicmp(Format, L"FAT") == 0)
BackwardCompatible = TRUE;
// else if (wcsicmp(Format, L"FAT32") == 0)
// 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;
}
DPRINT("Format() - %S\n", Format);
Success = Provider->Format(&usDriveRoot,
Callback,
QuickFormat,
BackwardCompatible,
MediaType,
&usLabel,
ClusterSize);
if (!Success)
DPRINT1("Format() failed\n");
/* Report success */
Callback(DONE, 0, &Success);
RtlFreeUnicodeString(&usDriveRoot);
}
/* EOF */