Restore von DOS Image, erweiterte Partition(en) fehlt

[fischfilet]

Ein Cluster ist die kleinste adressierbare Festplatteneinheit bei Windows-Betriebssystemen, hab ich mal gehört.

Cluster bezieht sich eindeutig auf das Dateisystem im Windows-Jargon, nicht auf den physikalischen Block (Sektor) des Datenträgers.

 

[mchawk777]

Ist auch eher ein Windowism, im Unix Umfeld ist mir das nie begegnet, hängt wahrscheinlich mit dem ganzen diesebezüglichen hysterischen Gezappel im Windows/Dos Umfeld zusammen, im Unix-Umfeld war das immer wesentlich sauberer wegabstahiert

So ist das halt mit den "Microsoft-Begriffen".

Unter Linux ist klar, was ein "Device" oder ein "Volume" ist.
Bei Microsoft gibt es das Wörtchen "Laufwerk", was je nach Kontext sowohl ein "Device" und/oder ein "Volume" bezeichnen kann. 🤷‍♂️

Ich spare mir jetzt die Geschichte bezüglich der korrekten Bezeichnung von Speichergrößen aufzuführen. Oops! Jetzt habe ich es doch gemacht. 😅

 

[recu]

Ein Cluster ist die kleinste adressierbare Festplatteneinheit bei Windows-Betriebssystemen, hab ich mal gehört.

Nein, die kleinste Einheit für Windows NT und alle folgende Derivate bei der Kommunikation mit Festplatten ist ein Sektor.

 

[foofoobar]

@recu Seit wann ist Windows der Maßstab für IT?

 

[wuselsurfer]

die kleinste Einheit für Windows NT und alle folgende Derivate bei der Kommunikation mit Festplatten ist ein Sektor.

Da bin ich anderer Meinung:

Das Dateisystem kann im Allgemeinen nur vollständige Cluster adressieren, es ist ohne Hilfe spezieller Programme nicht möglich, einzelne Sektoren oder gar einzelne Bytes innerhalb eines Clusters zu adressieren. Daher belegen Dateien auf einem Datenträger immer eine ganzzahlige Menge von Clustern.

 

[fischfilet]

die kleinste Einheit für Windows NT und alle folgende Derivate bei der Kommunikation mit Festplatten ist ein Sektor.

Nicht wenn es über das Dateisystem geht. Und auch Windows NT spricht NTFS nicht direkt auf den Blöcken der Festplatte an sondern über die Dateisystemtreiber.

 

[recu]

@recu Seit wann ist Windows der Maßstab für IT?

Windows NT ist ein zielgruppengerechtes Beispiel. Für die unixoide Welt gilt das genau so.

https://wiki.osdev.org/ATA_read/write_sectors

Ergänzung (Dienstag um 14:26)

Bei Microsoft gibt es das Wörtchen "Laufwerk", was je nach Kontext sowohl ein "Device" und/oder ein "Volume" bezeichnen kann. 🤷‍♂️

Es ist schon alles gesagt, nur nicht von jedem...

Ergänzung (Dienstag um 14:41)

Nicht wenn es über das Dateisystem geht. Und auch Windows NT spricht NTFS nicht direkt auf den Blöcken der Festplatte an sondern über die Dateisystemtreiber.

Die Dateisystemtreiber für NTFS und andere sind Bestandteil von Windows NT.

 

[mchawk777]

Es ist schon alles gesagt, nur nicht von jedem...

...ja - und Ad Hominem lassen sich gewisse Personen auch nicht als Stilmittel nehmen. 🤷‍♂️

 

[fischfilet]

Die Dateisystemtreiber für NTFS und andere sind Bestandteil von Windows NT.

Es ist aber ein Unterschied, ob das OS den Sektor roh ausliest oder über den Dateisystemtreiber.
Bei rohen Auslesen kann es klar einen bestimmten Block (Sektor) auf der Disk direkt lesen. Ähnlich wie dd unter Linux das macht. Gibt es direkte Bordmittel dazu von Window? Ich kenn nur den Hexeditor HxD mit dem man das kann und evtl. Partitioniertools.

 

[recu]

Hallo fischfilet,

Microsoft-Betriebssysteme stellen Dir eine API bereit.
Charles Petzold hat zur Windows-API ein Buch geschrieben. Für Linux gibt es äquivalentes.

https://learn.microsoft.com/en-us/windows/win32/fileio/opening-a-file-for-reading-or-writing

mit dem richtigen Präfix kannst Du anstelle von "normalen" Datei auch eine Festplatte öffnen wie eine Datei.

Dein Windows-Betriebssystem stellt Dir kein Tool bereit.
Für Deine Zwecke reicht vielleicht aber auch die Software "dd for Windows".

 

[fischfilet]

@recu
Brauchen tu ich das nicht, zumindest nicht unter Windows. Ich hab mich nur gefragt, ob es auch Bordmittel gibt. Ich kenn das rohe Auslesen wie gesagt bisher nur über Extratools wie HxD. (ja ein simpler Hexeditor kann direkt einen Datenträger aber auch den RAM öffnen und als hex darstellen).

 

[foofoobar]

Hallo fischfilet,

Microsoft-Betriebssysteme stellen Dir eine API bereit.
Charles Petzold hat zur Windows-API ein Buch geschrieben. Für Linux gibt es äquivalentes.

https://learn.microsoft.com/en-us/windows/win32/fileio/opening-a-file-for-reading-or-writing

mit dem richtigen Präfix kannst Du anstelle von "normalen" Datei auch eine Festplatte öffnen wie eine Datei.

Funktioniert das genauso scheiße wie mit "COM1:", "CON:" oder "LPT1:"?
Muss man sich dabei immer noch mit CTRL-Z rumärgern?

Dein Windows-Betriebssystem stellt Dir kein Tool bereit.
Für Deine Zwecke reicht vielleicht aber auch die Software "dd for Windows".

Unter Unix braucht es kein "dd", "cat" reicht völlig, selbst "gzip" kann direkt von block-devices lesen und schreiben.

 

[wuselsurfer]

Funktioniert das genauso scheiße wie mit "COM1:", "CON:" oder "LPT1:"?

COM 1 war die stabilste Verbindung aller Zeiten.
Direktes Kabelsignal, mehrfach geschirmt und geschirmte Stecker rundum.
Bei 9.600 bit/s konnte man zwar zusehen, wie die bits durch die Leitung flossen, aber Störungen waren so gut wie unbekannt.
Mit den späteren Karten (RS 485) konnte man auch mal mit ein paar hundert kbit/s kommunzieren.

Dagegen waren USB- und WLAN-Verbindungen wesentlich störanfälliger.

LPT 1 (parallele Schnittstelle) war etwas schneller, aber störanfälliger.
Aber der LQ 1050 hat eine Millisekunde nach dem ENTER-Befehl den Kopfschlitten in Bewegung gesetzt.
Der hat nicht erst überlegt, ob und wie man das Dokument denn drucken solle.
Und mit dem ACK Befehl waren die Kommandos immer rückversichert.

Muss man sich dabei immer noch mit CTRL-Z rumärgern?

Wer etwas falsch eingibt, braucht das.

Unter Unix braucht es kein "dd", "cat" reicht völlig, selbst "gzip" kann direkt von block-devices lesen und schreiben.

Wir sind hier aber bei DOS.

 

[foofoobar]

COM 1 war die stabilste Verbindung aller Zeiten.

Ich sprach von der Ansteuerung über das OS, nicht von Layer 1.

Und mit dem ACK Befehl waren die Kommandos immer rückversichert.

Ack war kein Befehl sondern ein Kabel/Leitung.

 

[wuselsurfer]

Ack war kein Befehl sondern ein Kabel/Leitung.

Acknowledge ist ein Signal (ASCII 06h), das über die besagte Leitung ausgegeben wurde.

Spoiler: ACK-Signal

Ein ACK-Signal (von englisch acknowledgement, in technischem Zusammenhang ‚Empfangsbestätigung‘, ‚Quittierung‘) ist ein Signal, das bei einer Datenübertragung verwendet wird, um den Erhalt oder die Verarbeitung von Daten oder Befehlen zu bestätigen.[1]

Das hat aber alles nichts mehr mit dem Thema zu tun.

 

[foofoobar]

Acknowledge ist ein Signal (ASCII 06h), das über die besagte Leitung ausgegeben wurde.

Macht bei einer unidirektionalen Schnittstelle wie Centronics wenig bis keinen Sinn, weswegen das auch als Kabel/Draht/Leitung implementiert wurde.

Das einzige Protokoll was ich gesehen habe was diese Sachen teilweise genutzt hat war: 3964R

 

[wuselsurfer]

Macht bei einer unidirektionalen Schnittstelle wie Centronics wenig bis keinen Sinn,

Lies Dir es einfach nochmal durch und gut ist es.