Forum Übersicht - A-Bajonett-Gehäuse (Digital) » Microdrive

Welche maximale Größe ist möglich? Benutzt die Dynyx 7D Fat 16 oder 32?

Gruß Klaus

Zitat von nthaegar

---

Welche maximale Größe ist möglich? Benutzt die Dynyx 7D Fat 16 oder 32?

---

Meines Wissens sowohl als auch. ;-)

Speziell zur Dynax 7 D kann ich nichts sagen, aber ich denke, daß die Kamera
Speichermedien bis mindestens 8 GB unterstützt (falls KoMi nur den Zugriff
über die CHS-Parameter implementiert hätte, was ziemlich unwahrscheinlich
wäre). Die nächste technische Schranke wäre dann bei ca. 128 GB bzw. 2 TB
für Zugriff über LBA-28/32. Ich denke, das dürfte auch die Grenze bei der
Dynax 7 D sein. Die Verwaltungsinformationen im Master Boot Record (der u.a.
für die Partitionierung verantwortlich ist) sind nur 32 Bit breit, darüber hinaus muß
man auf neuartige EFI (Extensible Firmware Interface) Partitionierungsmechanismen
ausweichen, die von heutigen Desktop-Systemen noch nicht vollständig unterstützt
werden, insofern wohl erst recht nicht von Embedded Systemen wie DSLRs.

Theoretisch sind mit FAT32 bis zu 8 bzw. 16 TB pro Partition möglich, aber auch dafür
fehlt derzeit noch die Unterstützung in gängigen Desktop-Betriebssystemen
wie Windows etc. (außer in DR-DOS ab 7.07, das zusätzlich noch eine proprietäre
Erweiterung von FAT32 namens FAT32B anbietet).
Die maximale DateigSeröße beträgt bei FAT16 2 GB (in nicht zu empfehlenden
Ausnahmefällen bis zu 4 GB), bei FAT32 in der Regel 4 GB (manche
Implementationen unterstützen aber auch hier "nur" 2 GB pro Datei, das inoffizielle
DR-DOS 7.01.0x und FreeDOS mit FATplus bis zu 128 GB große Dateien) -
dagegen sind die Bilder von Digitalkameras noch geradezu winzig. ;-)

Aus Kompatibilitäts- und Effizenzgründen sollte man für die Speicherung
von Bilddateien auf Speichermedien kleiner 2 GB aber *grundsätzlich*
das Dateisystem FAT16B alias "BIGDOS" (also 16-Bit-FAT mit 32-Bit-
Sektoreinträgen, Partitionstyp 06h, 0Eh etc.) statt FAT32 (Partitionstyp
0Bh, 0Ch etc.) verwenden, auch wenn viele heutige Betriebssysteme (und
möglicherweise auch die Kamera-Firmware) beim Formatieren/Partitionieren
der Medien FAT32 auch für kleinere Kapazitäten (ab etwa 512 MB) anbieten.
Letzteres hat gerade für den Anwendungsfall "Digitalkamera & Speicherung
von Fotos" wirklich nur Nachteile:

FAT32 ist nur bei Partitionen größer 2 GB wirklich notwendig, da DOS nur
maximal 64 Sektoren pro Cluster verwalten kann (maximale Clustergröße
32 KB) und man damit bei ca. 2^16 möglichen Clustern auf einer FAT16-
Partition und 512 Bytes pro Sektor auf maximal 2 GB pro Partition kommt.
Die technische Grenze liegt eigentlich bei 128 Sektoren pro Cluster (d.h.
Clustergröße 64 KB) bzw. 4 GB als maximaler Partitionsgröße, aber dies
wird leider von MS-DOS bis einschließlich Windows ME (MS-DOS 8.0) und
IBM PC DOS bis einschließlich PC DOS 2000 (PC DOS 7.0 Revision 1) und
OEM PC DOS 7.10 nicht unterstützt (aufgrund eines peinlichen Segment-
Überlauffehlers, der sich jahrzehntelang durch die Geschichte des Systems
gezogen hat), so daß man tunlichst die Finger davon lassen sollte, auch
wenn Windows NT/2000/XP, neuere Versionen von FreeDOS,
OEM DR-DOS 7.07 - 8.1 sowie Linux damit in der Regel zurecht kommen.

FAT32 wird bei der Speicherung von großen Dateien wirklich extrem ineffizient,
wenn man nicht riesengroße Zwischenspeicher für das Cachen der FAT zur
Verfügung hat - das ist aber weder bei DOS (das in einigen DSLRs zum
Einsatz kommt) noch bei anderen Betriebssystemen für Embedded Systems,
die allesamt mit vergleichsweise wenig RAM-Speicher auskommen müssen,
der Fall. Deren Caches puffern in der Regel nur einen oder mehrere für die
gerade geöffneten Dateien wichtige Teile der FAT sowie die Zuordnungsketten
der Verzeichniseinträge der entsprechenden Dateien. Zugriffe auf andere
Bereiche gehen durch bis auf's Medium und werden bei langsamen Medien
wie CF-Karten oder Mini-Festplatten zum echten Performance-Bottleneck.
Solange man nur bei FAT12 oder FAT16 bleibt, kommt man mit gerade mal
128 KB Speicher hin, selbst wenn man die komplette File Allocation Table (FAT)
zwischenspeichern wollte. Die wird nämlich bei FAT16 niemals größer als 128 KB -
im Gegensatz zu den in der Regel etlichen Megabyte (und im Extremfall bis zu
1 GB) bei FAT32.
Das bedeutet einerseits, daß ein signifikanter Anteil der Gesamtspeicherkapazität
des Mediums bei FAT32 schon mit Verwaltungsinformationen belegt wird, also nicht
mehr für Bilder zur Verfügung steht. Mit anderen Worten, auf einer 2 GB FAT16-
Partition kann man grundsätzlich mehr Nutzdaten (d.h. mehr Bilder! speichern
als auf einer äußerlich gleichgroßen 2 GB FAT32-Partition, auch wenn sich das
zunächst paradox anhört. Einzige Bedingung dafür ist, daß die durchschnittliche
Größe der Dateien größer ist als die jeweilige Clustergröße - bei "pathologischen"
Fällen wie 1 Byte-großen Dateien gilt dies also nicht, bei großen Bilddateien
aber immer.
Hinzu kommt, daß Dateien immer in Cluster-Ketten gespeichert werden und
für jeden belegten Cluster fallen weitere Verwaltungsstrukturen ab. Auf ein
FAT16-Laufwerk passen überschlagsweise 2^16 Dateien, auf ein FAT32-
Laufwerk heutiger Machart etwa 2^28. Dementsprechend kleiner ist bei gleicher
Partitionsgröße das Sektor-zu-Cluster-Verhältnis auf FAT32 gegenüber FAT16.
Bei heutzutage üblichen Kapazitäten liegt die Clustergröße in der Regel bei 8 KB
(bzw. 16:1 bei 512 Bytes pro Sektor) auf FAT32, bei einer 2 GB großen FAT16B-
Partition hingegen bei 64 KB (128:1 bei 512 Bytes). Damit sind weniger Cluster
pro Datei nötig, was erstens weniger zusätzliche Verzeichniseinträge bedeutet,
gleichzeitig aber auch kürzere Clusterketten. Kürzere Clusterketten widerum
bedeuten auf einem mobilen Medium signifikant höhere Zugriffsgeschwindigkeit,
eine höhere Ausfallsicherheit und bessere Recovery-Chancen bei Fehlern.

Mit anderen Worten, FAT16 ist für diesen Anwendungsfall um Größenordnungen
effizienter und schneller, außerdem passen mehr Bilder auf das Medium.

Hinzu kommt, daß das Dateisystem FAT16B (mit 32-Bit-Sektoreinträgen) von
nahezu jedem Betriebssystem der Welt gelesen und geschrieben werden kann,
da es bereits mit DOS ab 3.31 (1987) eingeführt wurde (das noch viel ältere
FAT12 (Partitionstyp 01h etc.) und FAT16 (Partitionstyp 04h etc.) mit 16-Bit-
Sektoreinträgen war auf Medien mit maximal 32 MB bzw. 512 MB beschränkt,
dürfte also für heutige Speicherkarten nicht mehr relevant sein).
FAT32 (egal welcher Untervariante) wurde aber erst mit DOS 7.10 (1997)
vorgestellt und fand erst deutlich später Einzug in andere Systeme (bei DR-DOS
ab 7.04) - einige Systeme unterstützen es bis heute nicht. D.h. wenn man in zehn
Jahren eine solche Karte lesen möchte, sind die Chancen sehr viel größer, daß
man dann noch ein System findet, das FAT16B-formatierte Karten lesen kann,
wohingegen FAT32 evtl. einige Jahre zu spät eingeführt wurde, um langfristig
gesehen wirklich relevant zu bleiben (auch wenn es im Moment wichtig ist).

Zusammenfassend kann man also sagen, daß FAT32 in unserem Metier der
Fotografie ausschließlich auf Medien mit mehr als 2 GB Sinn macht (und dort
auch nur, weil es keine echten Alternativen gibt). Sollte man also eine
Speicherkarte mit kleinerer Kapazität bereits als FAT32 formatiert haben, lohnt
sich die Umformatierung auf FAT16B. (Achtung: Vorher die Daten retten!

Auch wenn das keine knackige Antwort auf Deine konkrete Frage zur Dynax 7 D
ist, hoffe ich, daß ich vielleicht bei einigen ein wenig Bewußtsein für die generelle
Problematik dahinter schaffen konnte - nicht jeder will hochkapazitive Microdrives
anschließen...

Viele Grüße,

Matthias

PS. Übrigens, lange Dateinamen haben mit dem zugrundeliegenden Dateisystem
nichts zu tun, da sie als Meta-Informationen abgespeichert werden. Man kann also
selbst auf ältesten FAT12- und FAT16-Medien lange Dateinamen speichern,
auch wenn Windows das nicht in allen Fällen unterstützt.

Und was heißt das nun für die Praxis? Wenn ich mit der Standardfuktion der Kam formatiere, habe ich dann FAT16 oder FAT32?
Wie erzwinge ich FAT32? Sind die von dir beschriebenen Geschwindigkeits- und Kapazitätsvorteile nur theoretischer Natur, oder auch spürbar?

EDIT: Gilt das nur für Microdrives oder auch für CF-Karten?

Boah, das nenne ich mal eine umfassenden Beitrag. Nun aber mal DAUs gefragt:

Wie formatiere ich die Karten z.B. mit WIN2000 als FAT16B?

Viele Grüße,

Jörg

Verwende ein 4GB Hitatchi-Drive das die 7D ganz normal auf FAT32 formatiert und das einwandfrei funzt!

Zitat von kjebo02

---

Und was heißt das nun für die Praxis? Wenn ich mit der Standardfuktion der Kam formatiere, habe ich dann FAT16 oder FAT32?
Wie erzwinge ich FAT32? Sind die von dir beschriebenen Geschwindigkeits- und Kapazitätsvorteile nur theoretischer Natur, oder auch spürbar?

EDIT: Gilt das nur für Microdrives oder auch für CF-Karten?

---

Leider kann ich Dir die Frage nicht beantworten, bei welcher Medien-
kapazität zwischen 512 MB und 2 GB die Dynax 7 D als FAT16B oder
als FAT32 formatiert. Grundsätzlich sind in diesem Bereich beide
Dateisysteme möglich, wobei FAT32 nur Sinn macht, wenn man
mehr als ca. 2^16 Dateien auf dem Medium speichern muß oder die
Dateien im Mittel kleiner als die halbe jeweilige Clustergröße sind.
Die Clustergröße liegt in diesem Kapazitätsbereich irgendwo zwischen
4 KB und 64 KB, dagegen sind die Bilddateien deutlich größer - und
mehr als 2^16 davon passen sowieso nicht auf das Medium, also
macht FAT32 hier überhaupt keinen Sinn.

Unterhalb (bis runter auf 32 MB) wird immer als FAT16B formatiert,
darunter kommen dann evtl. noch das alte FAT16 oder FAT12 zum
Einsatz, aber das ist heute wohl nicht mehr relevant.

Oberhalb von 2 GB wird (von den erwähnen Ausnahmen abgesehen)
immer als FAT32 formatiert. Hier stellt sich die Frage der Effizenz
nicht (es ist nach wie vor nicht so effizient wie FAT16B es wäre), aber
solche Kapazitäten sind mit FAT16B aus technischen Gründen einfach
nicht möglich. Das ginge nur, wenn man mehr als eine Partition auf
dem Medium einrichtet, aber ich vermute, daß die Kamera-Firmware
davon nur die erste Partition sehen würde (kann ich mangels Dynax 7D
nicht ausprobieren) - ist halt kein Desktop-System, wo sowas selbst-
verständlich möglich wäre.

Die Geschwindigkeitsvorteile von FAT16B gegenüber FAT32 sind
gerade bei kleinen Systemen sehr deutlich wahrnehmbar, ich
kann Dir aber keine konkreten Zahlen zur Dynax 7 D geben, da
das von vielen Faktoren abhängt, insbesondere der Größe des
Caches und wie "intelligent" die Caching-Algorithmen für den
jeweiligen Anwendungsfall optimiert wurden. Die oft in der Windows-
Welt gehörte Aussage, daß FAT32 sogar schneller sei als FAT16,
stimmt jedenfalls so definitiv nicht für solcherart kleine Systeme,
die mit begrenzten Ressourcen auskommen müssen. Es ist hier
exakt anders herum. ;-)

Die Kapazitätsvorteile von FAT16B gegenüber FAT32 hängen
von der Größe der gespeicherten Dateien ab. In der Regel
hört man auch hier eine gegenteilige Aussage, nämlich, daß
FAT32 effizienter als FAT16B sei. Das stimmt sogar, aber nur
auf Desktop-Systemen, auf denen Dateien aller Größenordnungen
gespeichert werden, die aber im Durchschnitt deutlich kleiner
als die Clustergröße sind. Daß man auf einem Laufwerk nur
winzigkleine Dateien (< 2 KB) oder nur "riesengroße" Dateien
(> 64 KB) speichert, kommen auf solchen Systemen so nicht
vor. Auf einem Medium, auf dem aber nur Bilder gespeichert
werden, ist es jedoch der Fall. Insofern gilt hierfür, daß FAT16B
deutlich effizienter als FAT32 ist.

Ich kann Dir wie gesagt keine Meßwerte zur Dynax 7 D geben,
aber unter DOS (Paradebeispiel für ein kleines System, das
mit wenig Ressourcen auskommen muß kann man - je nach
Konfiguration - durchaus Performance-Unterschiede im Bereich
Faktor 10 - 50 feststellen. Aber um seriöse Werte zu liefern,
müßte man immer auch *konkrete* Angaben zur Größe der
Partition und der Größe und Anzahl der darauf gespeicherten
Dateien machen. Da das natürlich in der Praxis variabel ist,
habe ich stattdessen versucht, die Zusammenhänge zwischen
diesen Größen aufzuzeigen.

Da Microdrives und CF-Karten sich aus der Sicht des Systems
nur geringfügig unterscheiden, kann man das Gesagte auf
beides anwenden.

Um es nochmal auf den Punkt zu bringen: Unterhalb von 2 GB
ist FAT16B für den Anwendungsfall "Kamera" in allen Punkten
besser (d.h. schneller, effizienter, sicherer, kompatibler) als
FAT32, oberhalb hat man keine andere Wahl als FAT32.
Insofern solltest Du bei einer Kamera niemals FAT32 "erzwingen",
sondern eher versuchen, es zu vermeiden, solange es technisch
nicht notwendig ist.

Viele Grüße,

Matthias

Danke für die wieder sehr ausgiebige Antwort. Rein praktisch gesehen, bin ich genau so weit wie vorher! Was ist denn nun auf meinen Karten drauf?

FAT16 oder FAT32?

Selbst wenn ich mittels Explorer im WinXP auf Eigenschaften gehe, zeigt er mir an: "Dateisystem: FAT".

?

Wie krieg ich's raus?

Wenn der Explorer nur FAT anzeigt müsste es FAT 16 sein.

Also vergesst bitte mal Windows. Es geht um die Camera und die kann nur Laufwerke größer 2MB verarbeiten, wenn sie FAT32 unterstützt.
Das tut sie und somit ist meine Frage voll beantwortet.
Zur Zeit nutze ich ein 2GB Microdrive und ich habe mich gefragt, ob mehr möglich ist.
Es nützt nichts, wenn ein Laufwerk vom Rechner unterstützt wird und dann in der Camera nicht erkannt wird.

Gruß Klaus

ZITATWie formatiere ich die Karten z.B. mit WIN2000 als FAT16B?

Nutzt Windows 2000 noch fdisk?[/quote]
Die Fat wurde mit Fdisk eingestellt. Alles nach Win2000 sollte NTFS benutzen und wenn es FAT sein muß, dann FAT32. Das System entscheidet je nach Größe des Laufwerkes, welche FAT nötig ist.

Gruß Klaus

[EDIT: Zitat repariert durch Moderator.]

Zitat von Kurt G.

---

Wenn der Explorer nur FAT anzeigt müsste es FAT 16 sein.

---

Das ist in der Tat so. "FAT" steht für FAT12 und FAT16 (inkl. FAT16B) - und
"FAT32" eben für "FAT32" - fast immer... ;-)

Es gibt aber einige Bugs in der Windows-Implementierung, die unter bestimmten
Umständen dazu führen können, daß falsche Zeichenketten angezeigt bzw. sogar
schon bei der Formatierung falsch geschrieben werden.

Um es ganz genau zu ermitteln, als was das Medium vom Betriebssystem erkannt
und gemountet wurde, müßte man sich die Datenstrukturen des BIOS Parameter
Blocks (BPB) im Bootsektor der jeweiligen Partition anschauen. Mittels dieser
Werte kann man die Gesamtzahl der FAT-Einträge berechnen und dann anhand
bestimmter Schwellwerte in die drei Gruppen FAT12, FAT16 oder FAT32 einordnen.
Es gibt dort heutzutage auch eine Zeichenkette, die das Dateisystem in für
Menschen lesbarer Form spezifiziert (und von manchen Tools ausgegeben wird),
aber die ist nur kosmetischer Natur und man kann sich nicht darauf verlassen,
daß die Angabe wirklich immer existiert (manche FAT12 und FAT16 Partitionen
verwenden ältere BPB-Formate als das mit DOS 3.31 eingeführte, aber selbst
heute nicht immer zur Anwendung kommende XBPB (Extended BIOS Parameter
Block)-Format - die älteren teilweise recht OEM-spezifischen DOS-BPB Formate
oder das OS/2 1.x EBPB (Enhanced BIOS Parameter Block)-Format unterstützen
es z.B. nicht) bzw. daß die Angabe, falls vorhanden, auch wirklich stimmt (selbst
nicht immer bei FAT32, siehe oben).
Anhand des Formats der Datenstruktur im BPB lassen sich auch das alte FAT16
und das neuere FAT16B eindeutig voneinander unterscheiden.
Um Mißverständnissen vorzubeugen: Bei beiden, FAT16 und FAT16B, handelt es
sich im Prinzip um das gleiche Dateisystem; die neuere Variante unterscheidet sich
nur anhand des Bootsektors mit erweitertertem BPB (sog. XBPB - extended BIOS
parameter block mit 32-bittigen Sektoreinträgen gegenüber 16-bittigen Einträgen
vorher) und - bei partionierten Medien - anhand des anderen Partitionstyps. Das
allein reicht schon aus, um mit FAT16B auf maximale Partitionsgrößen von 2 GB
(4 GB) zu kommen, wohingegen das alte Format auf 32 MB - 512 MB (je nach DOS-
Version) beschränkt bleibt. Die Unterschiede sind zwar manchmal wichtig zu
wissen, aber in vielen Fällen nicht relevant, so daß man auch heute noch oft
allgemein von "FAT16" spricht, wenn man eigentlich FAT16B meint.
"FAT12" und "FAT16" unterscheiden sich zwar signifikant in der Breite und Anzahl
der FAT-Einträge, sind aber ansonsten von ihrer Grundkonzeption her so ähnlich,
daß sie oft einfach als "FAT" zusammengefaßt werden. "FAT32" (von dem es auch
wieder verschiedene Untervarianten gibt) ist hingegen viel mehr als einfach
ein "aufgebohrtes FAT"-Dateisystem, da sich auch viele andere semantische
Änderungen und Erweiterungen im Detail ergeben haben, was eine Vielzahl von
Sonderbehandlungen im Dateisystemtreiber erfordert. Deshalb wird "FAT32" in
der Regel gesondert genannt.

Eine andere, relativ (wenn auch nicht absolut) zuverlässige Methode, das
Dateisystem des Mediums zu ermitteln, ist es, den Partitionstyp im sog.
Master Boot Record (MBR) des physikalischen Mediums auszulesen.
Linux, DR-DOS und FreeDOS FDISK zeigen diese sog. Partition IDs in
Klarschrift an, Microsofts und IBMs FDISK leider nur in sehr begrenzter Form.
Ein Problem ist, daß die Ansteuerung von Wechselplatten in den unteren
Betriebssystemschichten so gekapselt d.h. abstrahiert wird, daß sie auf
höheren Ebenen meist nicht mehr als sog. Removable Drive sondern als
sog. Superfloppy dargestellt werden. D.h. das Medium sieht aus, als wäre
es nicht partioniert, obwohl es das in den meisten Fällen ist.
"Echte" Superfloppies (wie z.B. Flopticals, LS-120/240 Floppies, manche wenige
Memory Sticks) sind relativ wenig verbreitet - CF-Karten und Microdrives
sind jedenfalls defaultmäßig fast immer partionierte Medien (wie auch echte
Wechselplatten, ZIP- und JAZ-Laufwerke, die meisten Memory Sticks, etc.).
Bei einem Medium, das scheinbar (oder real) nicht partioniert ist, kann man
natürlich auch nicht den Partitionstyp auslesen. Nur Low-Level-Werkzeuge
helfen da weiter.
Hinzukommt, daß der Partitionstyp zwar von älteren Betriebssystemen
wie DOS, OS/2 und Windows 95/98/SE/ME ausgewertet wird, bei Linux und
Windows NT/2000/XP hat er jedoch fast keine funktionale Bedeutung mehr.
Fazit: Man muß sich stattdessen an den Bootsektor halten - den hat
ausnahmslos jedes Medium und er läßt sich meist auch einfacher auslesen.

Viele Grüße,

Matthias

PS. Wie kommt man an diesen Bootsektor eines Mediums? Unter der NT-Familie
ist das leider nicht mehr so einfach möglich, da direkte Laufwerkszugriffe -
zumindest aus dem 16-Bit-Subsystem heraus - in der Regel unterbunden
werden. (Ein Disk-Imager hilft z.B. weiter.) Aber wenn man ein DOS oder
DOS-basiertes Windows-System (3.x/95/98/SE/ME) hat, auf dem noch das
Werkzeug DEBUG zu finden ist (gehört zum Lieferumfang), kann man z.B.
folgenden Batchjob namens GETBOOT.BAT verwenden, um diesen Sektor
auszulesen, in einer Datei namens BOOT?.BIN zu speichern und nachher
in Ruhe anschauen zu können. Wichtig ist natürlich, daß man beim Aufruf
die dem austauschbaren Medium entsprechende Laufwerksnummer angibt.
Weitere Erläuterungen gibt es auch hier:

http://www.mi-fo.de/forum/index.ph...indpost&p=86407

@ ECHO off > \dev\nul
  ECHO GETBOOT V1.09 (051108)  Read out a drive's Boot Sector to a file
  ECHO Copyright (C) 1997,2005 Matthias Paul.  All rights reserved.
  REM -------------------------------------------------------------------------
  REM
  REM No warranties of any kind, neither expressed nor implied!
  REM Use at your own risk!
  REM
  REM Requirements:
  REM - Should run on DeviceLogics DR-DOS 7.07 - 8.1, OEM DR-DOS 7.04 - 7.06,
  REM   Caldera DR-DOS 7.02 - 7.03, Caldera DR-OpenDOS 7.02,
  REM   Caldera OpenDOS 7.01, Novell DOS 7, MS-DOS 5.0 - 8.0, PC DOS 5.0 - 7.10.
  REM - Runs under COMMAND.COM and 4DOS/NDOS.
  REM - DEBUG.EXE needs to be in the %PATH%.
  REM - Needs a logical sector size of 512 bytes.
  REM - The source medium must be ready and read accessible,
  REM   no error messages will be shown on failure!
  REM - Resident virus scanning software may pop-up alert boxes twice.
  REM   If you are prompted for user action, allow this batchjob to proceed
  REM   for things to work properly.
  REM - The logical destination drive must exist and be write accessible,
  REM   no error error messages will be shown on failure!
  REM -------------------------------------------------------------------------
  ECHO.
  IF ""=="%1" GOTO ok
  FOR %%x IN (0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12 13 14 15 16 17 18 19) DO IF "%1"=="%%x" GOTO ok
  ECHO Syntax: GETBOOT [drive # [destination file] ]
  ECHO         drive #          = 0..19 (hex) (default 2)
  ECHO         destination file = BOOT#.BIN
  ECHO.
  ECHO Ruler:  ABCDEFGHIJKLMNOPQRSTUVWXYZ
  ECHO         0123456789ABCDEF0123456789
  ECHO                         1
  GOTO end
:ok
  REM Note, that *no* error message will be shown if the medium is not ready!
  IF ""=="%1" ECHO L 100 2 0 1 > %tmp%\getboot.deb
  IF NOT ""=="%1" ECHO L 100 %1 0 1 > %tmp%\getboot.deb
  ECHO Rcx >> %tmp%\getboot.deb
  ECHO 200 >> %tmp%\getboot.deb
  IF ""=="%1" ECHO N boot2.bin >> %tmp%\getboot.deb
  IF ""=="%2" IF NOT ""=="%1" ECHO N boot%1.bin >> %tmp%\getboot.deb
  IF NOT ""=="%2" ECHO N %2 >> %tmp%\getboot.deb
  ECHO W 100 >> %tmp%\getboot.deb
  ECHO Q >> %tmp%\getboot.deb
@ DEBUG.EXE < %tmp%\getboot.deb > \dev\nul
  DEL %tmp%\getboot.deb > \dev\nul
  IF ""=="%1" IF EXIST boot2.bin ECHO Boot sector of drive 2 (C:) written to file BOOT2.BIN.
  IF ""=="%2" IF NOT ""=="%1" IF EXIST boot%1.bin ECHO Boot sector of drive %1 written to file BOOT%1.BIN.
  IF NOT ""=="%2" IF EXIST %2 ECHO Boot sector of drive %1 written to %2.
:end
  REM To avoid a parsing bug in an older MS-DOS COMMAND.COM...
  REM
 

Und hier ein ähnliches DOS-basiertes "Tool" GETMBR.BAT zum Auslesen des MBRs:

@ ECHO off > \dev\nul
  ECHO GETMBR V1.05 (051108)   Read out a drive's Master Boot Record to a file
  ECHO Copyright (C) 1997,2005 Matthias Paul.  All rights reserved.
  REM -------------------------------------------------------------------------
  REM
  REM No warranties of any kind, neither expressed nor implied!
  REM Use at your own risk!
  REM
  REM The resulting file is compatible with FDISK's OLDMBR[xx].BIN, but not with
  REM LOADER's LOADER.SAV (which additionally stores the file name as a header).
  REM
  REM Requirements:
  REM - Should run on DeviceLogics DR-DOS 7.07 - 8.1, OEM DR-DOS 7.04 - 7.06,
  REM   Caldera DR-DOS 7.02 - 7.03, Caldera DR-OpenDOS 7.02,
  REM   Caldera OpenDOS 7.01, Novell DOS 7, MS-DOS 5.0 - 8.0, PC DOS 5.0 - 7.10.
  REM - Runs under COMMAND.COM and 4DOS/NDOS.
  REM - DEBUG.EXE needs to be in the %PATH%.
  REM - Needs a physical sector size of 512 bytes.
  REM - The physical source drive must exist and direct disk access (for read)
  REM   must be permitted. Therefore, this may not work in some DOS emulators
  REM   (such as Windows NT/2000/XP).
  REM - The logical destination drive must exist and be write accessible,
  REM   no error error messages will be shown on failure!
  REM -------------------------------------------------------------------------
  ECHO.
  IF ""=="%1" GOTO ok
  FOR %%x IN (80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 8A, 8B, 8C, 8D, 8E, 8F) DO IF "%1"=="%%x" GOTO ok
  FOR %%x IN (90, 91, 92, 93, 94, 95, 96, 97) DO IF "%1"=="%%x" GOTO ok
  ECHO Syntax: GETMBR [drive # [destination file] ]
  ECHO         drive # = 80..97 (default 80)
  ECHO         destination file = MBR#.BIN
  ECHO.
  ECHO Ruler:  CDEFGHIJKLMNOPQRSTUVWXYZ (primary active boot partitions)
  ECHO         0123456789ABCDEF01234567
  ECHO         8               9
  GOTO end
:ok
  ECHO A 100 > %tmp%\getmbr.deb
  ECHO mov ax,0201 >> %tmp%\getmbr.deb
  ECHO mov bx,7C00 >> %tmp%\getmbr.deb
  ECHO mov cx,1 >> %tmp%\getmbr.deb
  ECHO mov dh,0 >> %tmp%\getmbr.deb
  IF ""=="%1" ECHO mov dl,80 >> %tmp%\getmbr.deb
  IF NOT ""=="%1" ECHO mov dl,%1 >> %tmp%\getmbr.deb
  ECHO clc >> %tmp%\getmbr.deb
  REM Note, that *no* error message will be shown if the drive is not ready!
  ECHO int 13 >> %tmp%\getmbr.deb
  ECHO. >> %tmp%\getmbr.deb
  ECHO G=100 110 >> %tmp%\getmbr.deb
  ECHO Rbx >> %tmp%\getmbr.deb
  ECHO 0 >> %tmp%\getmbr.deb
  ECHO Rcx >> %tmp%\getmbr.deb
  ECHO 200 >> %tmp%\getmbr.deb
  IF ""=="%1" ECHO N mbr80.bin >> %tmp%\getmbr.deb
  IF ""=="%2" IF NOT ""=="%1" ECHO N mbr%1.bin >> %tmp%\getmbr.deb
  IF NOT ""=="%2" ECHO N %2 >> %tmp%\getmbr.deb
  ECHO W 7C00 >> %tmp%\getmbr.deb
  ECHO Q >> %tmp%\getmbr.deb
@ DEBUG.EXE < %tmp%\getmbr.deb > \dev\nul
  DEL %tmp%\getmbr.deb > \dev\nul
  IF ""=="%1" IF EXIST mbr80.bin ECHO Master Boot Record of drive 80h (C:) written to file MBR80.BIN.
  IF ""=="%2" IF NOT ""=="%1" IF EXIST mbr%1.bin ECHO Master Boot Record of drive %1h written to file MBR%1.BIN.
  IF NOT ""=="%2" IF EXIST %2 ECHO Master Boot Record of drive %1h written to %2.
:end
  REM To avoid a parsing bug in an older MS-DOS COMMAND.COM...
  REM
 

Das Gegenstück zu GETBOOT.BAT heißt SETBOOT.BAT:

@ ECHO off > \dev\nul
  ECHO SETBOOT V1.07 (051108)  Write the contents of a file onto a drive's Boot Sector
  ECHO Copyright (C) 1997,2005 Matthias Paul.  All rights reserved.
  REM -------------------------------------------------------------------------
  REM
  REM No warranties of any kind, neither expressed nor implied!
  REM Use at your own risk!
  REM
  REM Requirements:
  REM - Should run on DeviceLogics DR-DOS 7.07 - 8.1, OEM DR-DOS 7.04 - 7.06,
  REM   Caldera DR-DOS 7.02 - 7.03, Caldera DR-OpenDOS 7.02,
  REM   Caldera OpenDOS 7.01, Novell DOS 7, MS-DOS 5.0 - 8.0 and PC DOS 5.0 - 7.10.
  REM - Run under COMMAND.COM and 4DOS/NDOS.
  REM - DEBUG.EXE needs to be in the %PATH%.
  REM - Needs a logical sector size of 512 bytes.
  REM - A valid (DOS) boot sector file, exactly 512 bytes long.
  REM - The (writable) medium must be ready, since no error message will be
  REM   shown on failure!
  REM -------------------------------------------------------------------------
  ECHO.
  IF ""=="%1" GOTO ok
  FOR %%x IN (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25) DO IF "%1"=="%%x" GOTO ok
  ECHO Syntax:  SETBOOT [drive # [source file] ]
  ECHO          drive #     = 0..25 (default 2)
  ECHO          source file = BOOT#.BIN
  ECHO.
  ECHO Ruler:   ABCDEFGHIJKLMNOPQRSTUVWXYZ (logical drives)
  ECHO          01234567890123456789012345
  ECHO                    1         2
  ECHO.
  ECHO Warning: SETBOOT is a very dangerous tool! Improper usage may
  ECHO          cause loss of all your data stored on your drives!
  GOTO end
:ok
  ECHO Warning: Writing erroneous info onto disk may lead into making
  ECHO          your drive non-bootable, or into serious loss of data!
  ECHO          Have boot floppies at hands!
  ECHO.
  IF ""=="%1" ECHO About to write file BOOT2.BIN onto boot sector of drive 2 (C:)...
  IF ""=="%2" IF NOT ""=="%1" ECHO About to write file BOOT%1.BIN onto boot sector of drive %1...
  IF NOT ""=="%2" ECHO About to write file %2 onto boot sector of drive %1...
  IF ""=="%1" IF NOT EXIST boot2.bin GOTO error
  IF ""=="%2" IF NOT ""=="%1" IF NOT EXIST boot%1.bin GOTO error
  IF NOT ""=="%2" IF NOT EXIST %2 GOTO error
  BREAK on > \dev\nul
  PAUSE Press any key to continue, or CTRL+C to exit!
  PAUSE Are you sure? This is your last chance to exit safely! Press CTRL+C to exit!
 
  REM Read the original boot sector and save away...
  IF ""=="%1" ECHO L 100 2 0 1 > %tmp%\setboot.deb
  IF NOT ""=="%1" ECHO L 100 %1 0 1 > %tmp%\setboot.deb
  ECHO Rcx >> %tmp%\setboot.deb
  ECHO 200 >> %tmp%\setboot.deb
  IF ""=="%1" ECHO N oldboot.2 >> %tmp%\setboot.deb
  IF NOT ""=="%1" ECHO N oldboot.%1 >> %tmp%\setboot.deb
  ECHO W 100 >> %tmp%\setboot.deb
 
  REM Store the new boot sector...
  IF ""=="%1" ECHO N boot2.bin >> %tmp%\setboot.deb
  IF ""=="%2" IF NOT ""=="%1" ECHO N boot%1.bin >> %tmp%\setboot.deb
  IF NOT ""=="%2" ECHO N %2 >> %tmp%\setboot.deb
  ECHO L 100 >> %tmp%\setboot.deb
  REM Note, that *no* error message will be shown if the medium is not ready!
  IF ""=="%1" ECHO W 100 2 0 1 >> %tmp%\setboot.deb
  IF NOT ""=="%1" ECHO W 100 %1 0 1 >> %tmp%\setboot.deb
  ECHO Q >> %tmp%\setboot.deb
@ DEBUG.EXE < %tmp%\setboot.deb > \dev\nul
  IF ""=="%1" If EXIST oldboot.2 ECHO Old boot sector written to file OLDBOOT.2.
  IF NOT ""=="%1" If EXIST oldboot.%1 ECHO Old boot sector written to file OLDBOOT.%1.
  DEL %tmp%\setboot.deb > \dev\nul
  ECHO Done.
  GOTO end
:error
  ECHO Error: File not found! Type SETBOOT /h for help.
:end
  REM To avoid a parsing bug in an older MS-DOS COMMAND.COM...
  REM
 

Hier das Gegenstück zu GETMBR.BAT namens SETMBR.BAT:

@ ECHO off > \dev\nul
  ECHO SETMBR V1.05 (051108)   Write a file onto a drive's Master Boot Record
  ECHO Copyright (C) 1997,2005 Matthias Paul.  All rights reserved.
  REM -------------------------------------------------------------------------
  REM
  REM No warranties of any kind, neither expressed nor implied!
  REM Use at your own risk!
  REM
  REM Requirements:
  REM - Should run on DeviceLogics DR-DOS 7.07 - 8.1, OEM DR-DOS 7.04 - 7.06,
  REM   Caldera DR-DOS 7.02 - 7.03, Caldera DR-OpenDOS 7.02,
  REM   Caldera OpenDOS 7.01, Novell DOS 7, MS-DOS 5.0 - 8.0 and PC DOS 5.0 - 7.10.
  REM - Run under COMMAND.COM and 4DOS/NDOS.
  REM - DEBUG.EXE needs to be in the %PATH%.
  REM - Needs a physical sector sizer of 512 bytes.
  REM - A valid (DOS) Master Boot Record, exactly 512 bytes long.  The MBR file
  REM   is compatible with FDISK's OLDMBR[xx].BIN, but not with LOADER's
  REM   LOADER.SAV (which additionally stores its file name as a header).
  REM - The physical destination drive must exist and direct disk access
  REM   (for read and write) must be permitted. Therefore, this may not work
  REM   in some DOS emulators (such as Windows NT/2000/XP/2003).
  REM - Resident virus scanning software may pop-up alert boxes twice.
  REM   If you are prompted for user action, allow this batchjob to proceed
  REM   for things to work properly.
  REM - No error error messages will be shown on failure!
  REM -------------------------------------------------------------------------
  ECHO.
  FOR %%x IN (80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 8A, 8B, 8C, 8D, 8E, 8F) DO IF "%1"=="%%x" GOTO ok
  FOR %%x IN (90, 91, 92, 93, 94, 95, 96, 97) DO IF "%1"=="%%x" GOTO ok
  ECHO Syntax:  SETMBR drive # [source file]
  ECHO          drive #     = 80..97
  ECHO          source file = MBR#.BIN
  ECHO.
  ECHO Ruler:   CDEFGHIJKLMNOPQRSTUVWXYZ (primary active boot partitions)
  ECHO          0123456789ABCDEF01234567
  ECHO          8               9
  ECHO.
  ECHO Warning: SETMBR is a very dangerous tool! Improper usage may
  ECHO          cause loss of all your data stored on your drives
  ECHO          (including non-DOS partitions)! Setting environment variable
  ECHO          SET %% SETMBR %% = PART will also overwrite the partition table,
  ECHO          otherwise only the executable MBR code will be refreshed and
  ECHO          Advanced Active Partitions or Windows Volume Bytes be resetted!
  GOTO end
:ok
  ECHO Warning: Writing erroneous info onto disk may lead into making
  ECHO          your drive non-bootable, or into serious loss of all
  ECHO          your data! Have boot floppies at hands!
  ECHO.
  IF NOT "PART"=="%SETMBR%" ECHO          SETMBR will *not* overwrite the partition table.
  IF "PART"=="%SETMBR%"     ECHO          SETMBR *will* also overwrite the partition table!
  ECHO.
  IF ""=="%2" ECHO About to write file MBR%1.BIN onto Master Boot Record of drive %1...
  IF NOT ""=="%2" ECHO About to write file %2 onto Master Boot Record of drive %1...
  IF ""=="%2" IF NOT EXIST mbr%1.bin GOTO error
  IF NOT ""=="%2" IF NOT EXIST %2 GOTO error
  BREAK on > \dev\nul
  PAUSE Press any key to continue, or CTRL+C to exit!
  PAUSE Are you sure? This is your last chance to exit safely! Press CTRL+C to exit!
 
  REM Load the original MBR image from disk...
  ECHO A 100 > %tmp%\setmbr.deb
  ECHO mov ax,0201 >> %tmp%\setmbr.deb
  ECHO mov bx,5000 >> %tmp%\setmbr.deb
  ECHO mov cx,1 >> %tmp%\setmbr.deb
  ECHO mov dh,0 >> %tmp%\setmbr.deb
  ECHO mov dl,%1 >> %tmp%\setmbr.deb
  ECHO clc >> %tmp%\setmbr.deb
  REM Note, that *no* error message will be shown if the drive is not ready!
  ECHO int 13 >> %tmp%\setmbr.deb
  ECHO. >> %tmp%\setmbr.deb
  ECHO G=100 110 >> %tmp%\setmbr.deb
 
  REM Store the original MBR in OLDMBR?.BIN...
  ECHO Rbx >> %tmp%\setmbr.deb
  ECHO 0 >> %tmp%\setmbr.deb
  ECHO Rcx >> %tmp%\setmbr.deb
  ECHO 200 >> %tmp%\setmbr.deb
  ECHO N oldmbr%1.bin >> %tmp%\setmbr.deb
  ECHO W 5000 >> %tmp%\setmbr.deb
 
  REM Now load the new MBR image into memory...
  IF ""=="%2" ECHO N mbr%1.bin >> %tmp%\setmbr.deb
  IF NOT ""=="%2" ECHO N %2 >> %tmp%\setmbr.deb
  ECHO L 7C00 >> %tmp%\setmbr.deb
 
  REM Now copy the new image over the old image...
  IF NOT "PART"=="%SETMBR%" ECHO M 7C00 L 1BE 5000 >> %tmp%\setmbr.deb
  IF "PART"=="%SETMBR%" ECHO M 7C00 L 200 5000 >> %tmp%\setmbr.deb
 
  REM Store the new MBR image on disk...
  ECHO A 100 >> %tmp%\setmbr.deb
  ECHO mov ax,0301 >> %tmp%\setmbr.deb
  ECHO. >> %tmp%\setmbr.deb
  ECHO G=100 110 >> %tmp%\setmbr.deb
 
  REM Exit DEBUG...
  ECHO Q >> %tmp%\setmbr.deb
 
  REM Now, go for it...
@ DEBUG.EXE < %tmp%\setmbr.deb > \dev\nul
  IF EXIST oldmbr%1.bin ECHO Old MBR written to file OLDMBR%1.BIN.
  DEL %tmp%\setmbr.deb > \dev\nul
  ECHO Done.
  GOTO end
:error
  ECHO Error: File not found! Type SETMBR /h for help.
:end
  REM To avoid a parsing bug in an older MS-DOS COMMAND.COM...
  REM
 

Zitat von nthaegar

---

Also vergesst bitte mal Windows. Es geht um die Camera und die kann nur Laufwerke größer 2MB verarbeiten, wenn sie FAT32 unterstützt.
Das tut sie und somit ist meine Frage voll beantwortet.
Zur Zeit nutze ich ein 2GB Microdrive und ich habe mich gefragt, ob mehr möglich ist.
Es nützt nichts, wenn ein Laufwerk vom Rechner unterstützt wird und dann in der Camera nicht erkannt wird.

Gruß Klaus

---

Du meinst 2 GB, nicht wahr? ;-)

Okay, wenn Du ein 2 GB Microdrive hast, solltest Du es als FAT16B
formatieren. Das ist gerade an der Grenze dessen, was mit FAT16B
machbar ist und es ist für den Anwendungsfall "Kamera" besonders
effizient so. FAT32 wäre es nicht.

Was die Zukunft angeht, bis ca. 8 GB sollte es überhaupt keine Probleme
geben. Sollte jemand das erste Mal ein Medium mit mehr als 8 GB erfolgreich
in der Kamera verwendet haben und davon hier berichten, so ist die
Wahrscheinlichkeit groß, daß es danach bis ca. 128 GB (evtl. auch bis
2 TB) keine Probleme mehr gibt (also Spielraum für die nächsten fünf
bis sieben Jahre ;-).

Viele Grüße,

Matthias

Zitat von nthaegar

---

Die Fat wurde mit Fdisk eingestellt. Alles nach Win2000 sollte NTFS benutzen und wenn es FAT sein muß, dann FAt 32. Das System entscheidet je nach Größe des Laufwerkes, welche FAT nötig ist.

Gruß Klaus

---

Selbst Windows XP unterstützt noch FAT12, FAT16 und selbstverständlich FAT32.

NTFS sollte man auf einem Wechselmedium natürlich überhaupt nicht
benutzen, da ist der Super-GAU regelrecht vorprogrammiert. Außerdem
würde es die Kamera nicht verstehen.

Viele Grüße,

Matthias

PS. Meine Postings waren so ausführlich, da ich über Dein konkretes Problem
hinaus die generelle Problematik auch für andere Leser darstellen wollte.

PS2: Ein Nachfolge-Thread findet sich hier:

http://www.mi-fo.de/forum/viewtopic.php?t=7446
http://www.mi-fo.de/forum/index.ph...ost&p=86226
http://www.mi-fo.de/forum/index.ph...ost&p=86726
http://www.mi-fo.de/forum/viewtopic.php?t=10418
http://www.mi-fo.de/forum/viewtopic.php?t=10569
http://www.mi-fo.de/forum/index.ph...st&p=188795

ZITATDu meinst 2 GB, nicht wahr? ;-) /wub.gif" style="vertical-align:middle" emoid="" border="0" alt="wub.gif" />[/quote]
Klar 2 GB, sorry

Die Preise purzeln und ich habe 4 GB schon unter 200€ gesehen.

Gruß Klaus

[EDIT: Zitat repariert durch Moderator.]

ZITAt (matthiaspaul @ 2.02.2005 - 22:17) Was die Zukunft angeht, bis ca. 8 GB sollte es überhaupt keine Probleme
geben. Sollte jemand das erste Mal ein Medium mit mehr als 8 GB erfolgreich
in der Kamera verwendet haben und davon hier berichten, so ist die
Wahrscheinlichkeit groß, daß es danach bis ca. 128 GB (evtl. auch bis
2 TB) keine Probleme mehr gibt (also Spielraum für die nächsten fünf
bis sieben Jahre ;-).[/quote]
Zumindest der 8 GB Grenze nähern wir uns inzwischen. Es gibt erste Erfolgsmeldungen von 8 GB CF-Karten in der Dynax 7 D:

http://www.photo.net/bboard/q-and-a-fetch-msg?msg_id=00GsOF

Richtig interessant wird es allerdings erst, wenn jemand mal 8,5 GB oder mehr probiert hat...

Viele Grüße,

Matthias