Zunächst möchte ich zwei sehr unterschiedliche Dinge unterscheiden:
- Wie die Implementierung des proprietären
convert.exeBetriebssystems unter Windows für diese direkte Konvertierung des Dateisystems zwischen FAT32 und NTFS sorgt. - Wie könnte man im Allgemeinen das Problem der Konvertierung zwischen zwei Dateisystemen an Ort und Stelle angehen, ohne dass 2x der gewünschte Speicherplatz zur Verfügung steht, oder interoperable Metadaten zwischen den beiden Dateisystemen oder andere solche Feinheiten, die das Problem trivial machen würden?
Im ersten Fall sind wir Microsoft in der Regel bei der Veröffentlichung dieser Informationen behilflich, da jeder, der Zugriff auf die Windows-Quelle erhält, einen NDA unterschreiben muss. Es würde nur freigegeben, wenn es von Microsofts rechtlichem Team genehmigt wurde. Sicher, vielleicht hat jemand, der diese Frage liest, eine illegale Kopie der durchgesickerten Windows-Quelle erhalten und dies aus dem Code herausgefunden, aber das ist eine legale Grauzone.
Deshalb werde ich nicht versuchen, auf die erste Frage eine Antwort zu geben, da ich keine Antwort habe.
Ich werde jedoch die zweite Frage beantworten.
In der Geschichte von Dateisystemen gab es viele Fälle, in denen wir ein Upgrade von einem Dateisystem auf ein anderes durchführen wollten, ohne das Betriebssystem zu löschen, eine Neuinstallation durchzuführen oder eine zweite Festplatte zu verwenden. Um ein paar zu nennen:
- Im Jahr 2017 erhielten alle, die ein Apple iOS-Gerät auf iOS 10.3 aufgerüstet haben, ein direktes Dateisystem-Upgrade von HFS + auf APFS im integrierten NAND ihres iDevice.
- Btrfs unterstützt seit Jahren das direkte Upgrade eines Dateisystems von ext4 auf btrfs mit dem Tool btrfs-convert .
Das Open Source- Programm fstransform gibt vor, zwischen vielen verschiedenen Dateisystemen zu konvertieren (mit einigen Einschränkungen und Einschränkungen) - und es enthält viele / gängige Linux-Dateisysteme sowie beeindruckend NTFS! FAT32 wird noch nicht unterstützt, obwohl viele andere Dateisysteme unterstützt werden.
Wenn Sie den C ++ - Code lesen, erhalten Sie das detaillierteste technische Wissen, das Sie über die allgemeinen Algorithmen für die Konvertierung zwischen unterschiedlichen Dateisystemen benötigen, selbst wenn Kompatibilität oder Interoperabilität weder von den ursprünglichen Dateisystemautoren (weder vom Quell noch vom Ziel-Dateisystem) geplant oder entworfen wurden !).
Der allgemeine Prozess würde in großen Zügen so aussehen:
- Gehen Sie den Datei- / Verzeichnisbaum des aktuellen Dateisystems durch. Erstellen Sie in einer neuen gewöhnlichen Datei innerhalb des vorhandenen Dateisystems die FS-spezifische Dateitabelle (Liste der Dateien, Verzeichnisse, symbolischen Links, Berechtigungen usw.) basierend auf der aktuellen Dateisystemliste, jedoch im Format des neuen Dateisystems .
- Formatieren Sie die Datenstrukturen und In-Place-Metadaten des alten Dateisystems im Hinblick auf die Datenstrukturen des neuen Dateisystems neu, und aktualisieren Sie die Zeiger (gegebenenfalls auf logische Plattenblöcke und Offsets) in der neuen Dateitabelle, um auf die neu berechnete Datei zu verweisen / Verzeichnis / Berechtigungsblöcke (mit allgemeinen Konzepten wie "Inodes" oder "Streams", abhängig davon, von welchem Dateisystem aus / in dieses konvertiert wird, kann dies variieren).
- Überschreiben Sie am Ende des Prozesses die Metadaten des ursprünglichen Dateisystems (die das Dateisystem mithilfe von magischen Zahlen usw. als alten Dateisystemtyp identifizieren) destruktiv mit den Metadaten des neuen Dateisystems, und erstellen Sie die entsprechenden Zuordnungen, die auf den "Superblock" verweisen. "MFT" oder welche dateisystemspezifischen Datenstrukturen sind erforderlich, damit sich das Dateisystem selbst initialisieren kann.
- Aktualisieren Sie die globale Datenträger- Partitionstabelle (z. B. MSDOS-Format oder GPT-Format). Aktualisieren Sie ggf. die Magic-Nummer, die auf den in der Partition enthaltenen Dateisystemtyp verweist (Hinweis: Bestimmte Dateisysteme verwenden dieselbe Magic-Nummer, da AFAIK nur eine 16 Es gibt nur 65.535 Möglichkeiten. Einige Dateisystemtreiber sind intelligent genug, um die magische Zahl zu ignorieren und die tatsächlichen Datenstrukturen des Dateisystems zu "prüfen", um festzustellen, ob diese Partition eine Instanz eines bestimmten Dateisystems enthält.
Es ist erwähnenswert, dass die letzten beiden Schritte zumindest nicht atomar sind; Das bedeutet, die üblichen Atomitätsgarantien eines Journaldateisystems (wie NTFS, Reiserfs, XFS, ZFS usw.) sind nicht verfügbar. Wenn das System abstürzt oder sich abschaltet oder das Benutzerraumprogramm, das die Konvertierung durchführt, abstürzt oder während dieses Vorgangs abstürzt, ist für das Dateisystem ein Datenwiederherstellungsexperte erforderlich, um Ihre Daten wiederherzustellen oder die Vernunft im (alten oder neuen) Dateisystem wiederherzustellen. Während dieser "destruktiven" Vorgänge führt das zugrunde liegende Speichermedium destruktive Überschreibungen kritischer Daten auf eine Weise durch, die nicht durch ein Dateisystemjournal gesichert wird, da der Prozess das Journal des alten Dateisystems von Natur aus umgeht (um von einem zu wechseln) FS zu einem anderen, Sie können das alte Dateisystem nicht anweisen, sich selbst "sicher zu töten", indem Sie die Kernmetadaten mit etwas anderem überschreiben, von dem es noch nichts weiß.
Im Gegensatz dazu ist die Aufforderung an ein Dateisystem, das Datenjournal für ein normales Schreiben ausführt, tatsächlich atomar: Entweder ist das gesamte Schreiben abgeschlossen oder es wird überhaupt nicht ausgeführt (das unvollständige teilweise Schreiben in den Journalbereich kann rückgängig gemacht werden, wenn das Systemabstürze auf halben Weg durch das schreiben, das, was ist fsckoder chkdskProgramme tun auf Boot-up nach Ihrem System BSODs oder Kernel - Fehler.)
Eine In-Place-FS-Konvertierung ist ziemlich riskant - sie ist ungefähr so riskant wie ein BIOS-Flash (mehr auf mobilen Geräten, bei dem Sie Ihr Gerät dauerhaft mit einem nicht bootfähigen Betriebssystem ausbilden können), da die Sicherheit vieler Operationen nicht gewährleistet ist Dies dauert in der Regel sehr lange. Daher besteht eine hohe Wahrscheinlichkeit, dass der Benutzer den Eindruck hat, das Betriebssystem sei hängengeblieben, und das Gerät würde während des Umbaus aus- und wieder eingeschaltet oder ein batteriebetriebenes Gerät ist leer.
Weitere Einblicke in, wie dies getan werden sicherer mit dem Wissen der Zusammenarbeit von zwei Dateisysteme, die sind entworfen zwischen einem zum anderen zu konvertieren (das war, wie ich es verstehe, der Fall mit dem HFS + zu APFS Umwandlung auf iOS), dieses faszinierende talk verwendet einen forensischen Ansatz, um herauszufinden, was mit APFS los ist. Das Konvertierungsproblem wird nicht direkt angegangen, jedoch können aus den bereitgestellten Informationen einige Details zur Konvertierung abgeleitet werden.
Dies ist alles zu sagen, eine endgültige Antwort kann nie auf Ihre genaue ursprüngliche Frage gefunden werden, aber ich denke, wenn Sie viel Wissen über den allgemeinen Prozess der In-Place-FS-Konvertierung erhalten, sollten Sie genügend Anhaltspunkte haben, um das zu enträtseln, was wahrscheinlich ist der Prozess für sein convert.exe.
Übrigens dachte ich ursprünglich "Oh, toll, ReactOS wird dieses Tool bereits implementiert haben und wir können einfach den Quellcode sehen!" - Nein. Sie haben convert.exe nicht auf ReactOS implementiert. Wenn es von allen Benutzern auf ihrem System überhaupt verwendet wird, müssen sie die proprietäre MS Windows-Binärdatei ausführen. Ansonsten bieten sie dieses Dienstprogramm in ReactOS einfach nicht an.