Hallo,
ich habe in der Arbeit ein kleines Problem. Ich soll ein Image von einer
Compactflash-Karte ziehen und dieses auf andere Karten clonen. Bei
Test's ist mir aufgefallen das Linux immer mehr Sektoren erkennt als
Windows. Der Hex-Editor zeigt mir auch zu wenige Sektoren an (Tiny-Hex).
Hat jemand einen Anhaltspunkt worann dies liegen könnte?
P.S. Ich habe den Test auch mit Compactflash-Karten gemacht, bei denen
ich zuvor den gesamten Speicherbereich auf Nullen gesetzt habe.
Hallo Flo,
ganz sicher bin ich mir nicht, hab unter Windows noch nie mit Images
gearbeitet.
Könnte es daran liegen, dass Du unter Linux das ganze Device ausliest
(/dev/sdx) und unter Window evl. die Partitionstabelle nicht mitgelesen
wird?
Gruß
Sebastian
Mir fällt das immer bei qtparted auf, dass es noch ein paar freie
Sektoren meldet.
(Knoppix CD booten, eine rootshell aufrufen und dort "qtparted" starten,
das braucht root-Rechte)
Hallo,
hier wahr schon länger nichts mehr los ;-). Hab das Thema vor kurzem
wieder auf den Tisch bekommen. Ich lasse mir von Windows per "OpenFile"
(aus der WinAPI) einen Handle auf das Laufwerk geben. Dieses lese ich
mit "ReadFile" Byteweise aus. Auch der Zugriff per "DeviceIOControl"
funktioniert, um mir die DiskParameter anzeigen zu lassen. Nur zeigt er
mir wieder nur die typischen Windowsangaben an (zu wenige Sektoren;-) ).
Hat jemand eine Ahnung wie ich über WinAPI Funktionen eine
CompactFlash-Karte (per USB-Kartenleser angeschlossen) hardwarenah
auslesen kann? Ich weiß das es funktionieren muss, da das Programm
"WinHEX" mir auch die "Überhangsektoren" des Datenträgers anzeigt.
> Ich lasse mir von Windows per "OpenFile"> (aus der WinAPI) einen Handle auf das Laufwerk geben.
Welches Laufwerk? Das physikalische oder das logische?
Das ist nicht das physikalische Laufwerk, sondern das logische Laufwerk.
Mit \\.\PHYSICALDRIVE0 hingegen wird auf das physikalische Laufwerk
(hier: die erste Festplatte) zugegriffen.
Der Unterschied zwischen physikalischem und logischen Laufwerk wird
schnell klar, wenn man an Partitionen denkt. Auf einer Festplatte ist
immer (mindestens) eine Partition. Der erste 512-Byte-Block des
physikalischen Laufwerks enthält die Partitionstabelle sowie den "master
boot record" (MBR), der erste 512-Byte-Block eines logischen Laufwerks
enthält den je nach installiertem Betriebssystem unterschiedlichen
Bootsektor.
Ok den Fehler geb ich zu. Ich kenne zwar den Unterschied, hab ich aber
anscheinend kurz vergessen ;-). Das ändert aber leider nichts am
Ergebnis.
Kann es sein, das ich solche Abfragen per ATA-Kommandos machen muss?
Sprich, direkt mit der Hardware kommunizieren? Den Bereich den ich
auslesen möchte liegt ja eingentlich im gemapten Speicherbereich, der
normalerweise vom Controller verwaltet wird. Oder?
So wie es aussieht kann ich aber keine ATA-Kommandos über die USB
Schnittstelle an ein USB-Mass-Storage-Device schicken, bzw. die Doku
gibt darüber wenig her. Es gibt zwar laut CF-spec eine Kommando das so
gut wie alle Hardwareinformationen liefert. Ich weiß aber nicht wie ich
es absenden kann.
Hallo,
hat jemand vielleicht eine Ahnung, wie ich mit IOCTL-Codes SCSI bzw. ATA
Kommandos an den Cardreader schicken kann? Bisher habe ich nur
Fehlermeldungen erhalten. Als Treiber benutze ich den Standard Windows
"USB-Mass-Storage"-Treiber.
Das wird der Cardreader nicht unterstützen.
Einzige Möglichkeit, die ich sehe, ist die Verwendung eines
IDE-Adapters, mit dem die CF-Karte im TrueIDE-Modus betrieben wird ...
und der am IDE-Anschluss des Rechners hängt.
Hallo Rufus,
irgendwie muss es aber doch möglich sein, da WinHEX meiner Meinung nach
auch auf die internen Register der Karte zugreift, um die
Überhangsektoren auszulesen. Laut der USB-Mass-Storage-Spec sollten die
Treiber aber auch in der Lage sein solche Kommandos weiterzureichen. Ich
verwende hier einen Sandisc-Imagemate-CF-Reader. Falls das weiterhelfen
sollte.
Bei Test mit "IOCTL_SCSI_PASS_THROUGH_DIRECT" gibt er mir auch keinen
Fehler aus wie "Kommando wird nicht unterstützt", sondern er läuft
entweder in den Timeout, oder ein Device-Fehler tritt auf.
Laut dem Programm USBMon (USB-Sniffer) schickt WinHEX an den Kartenleser
SCSI-Kommandos. Das unterstützte Protokoll (SCSI,...) ist abhängig von
der "InterfaceSubClass" des USB-Deskriptors. Bei 0x06h unterstütz das
Medium bzw. der Reader SCSI-Kommandos. Bleibt nur noch die Frage, wie
sieht der Beispielcode aus um solche Kommandos abzusetzen (z.b. das
INQUIRY Kommando)
IOCTL_SCSI_PASS_THROUGH_DIRECT und IOCTL_SCSI_PASS_THROUGH haben so ihre
speziellen Tücken, die mehr oder weniger garnicht dokumentiert sind,
weil sie u.a. vom angesprochenen Treiberstack abhängig sind.
Eine besondere Tücke liegt aber auch im Unterschied der beiden: Für
kleine Puffer muß man - zumindest bei IDE/ATAPI mit
IOCTL_SCSI_PASS_THROUGH behandeln, sonst bleibt die Chose irgendwann
unvermittelt hängen und nichts geht mehr - auf dem ganzen Rechner.
Wenn du damit anfängst, wirst du viel Spaß haben... deshalb würde ich
dir zuerst mal empfehlen, das physikalische Device zu öffnen und zu
versuchen mit den üblichen Blocklesekommandos ganze Sektoren zu lesen.
Die Lesekommandos, die du von WinHEX auf dem Device siehst, werden mit
ziemlicher Sicherheit nicht von WinHEX erzeugt, sondern von den Treibern
auf dem Stack, die die Highlevellesekommandos in SCSI-Kommandos
umsetzen. Was man sieht, hängt im wesentlichen davon ab, wo im Stack der
Filtertreiber des Sniffers sich einhängt.
Hallo Uhu Uhuhu,
ich bin jetzt schon einen Megaschritt weiter. Ich habe es geschafft mir
eine eigene Wrapper-DLL zu schreiben, die mir die CreateFile,
CloseHandle und DeviceIOControl Kommandos für LabView vorbereitet. Ich
hab es auch geschafft Low-Level auf USB-Mass-Storage Geräte zuzugreifen.
Die ist durch das Kommando SCSI_PASS_THROUGH_DIRECT möglich. Ich
reserviere und beschreibe einen max 64kB großen Speicherbereich, dessen
Zeiger ich der Struktur übergebe. Funktioniert prächtig. Laut Microsoft
müssen alles USB-Mass-Storage Treiber einen Grundstock von
SCSI-Kommandos übersetzen können. Das währen unter anderem INQUIRY,
READ(10), WRITE(10) und READ CAPACITY. Theoretisch könnte ich damit 2TB
an Daten adressieren. Dürfte also für die nächsten Generationen von
Speicherkarten ausreichen. Bei ersten Test hab ich eine, natürlich von
CF-Card abhängig, maximale Übertragungsrate von 12MB/s Lesend und 10MB/s
schreibend erreicht. Habs auch schon geschafft 4 Kartenleser
gleichzeitig zu beschreiben, leider bricht dabei die Performance um ca.
2 MB/s zusammen. Bin aber noch dabei herauszufinden warum.
Zusätzlich ist es mir gelungen einen MD5-Hash Generator für die
Speicherkarten zu schreiben. Dadurch bin ich in der Lage die
Originalimagedatei mit dem Inhalt der Device zu vergleichen. Alles in
allem ein netter Speicherkartenkopieren mit wirklichem 1:1 Verhältnis.
Es gibt zwar bereits einen Hersteller für solche Software, nur diese
schafft es nicht die Überhangsektoren mitzuschreiben.
Also bye und danke an alle nochmal für ihre Antworten.
P.S. Dieses Forum ist echt das beste seiner Art. Hier wird wenigstens
noch anständig geantwortet.
