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?
Ja, das 'identify device'-Kommando muss auf beiden Platformen die gleichen Daten zurückgeben.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.