Software > Alternative Betriebssysteme
MAGX´ Macken
czietz:
--- Zitat von: 1ST1 am Mi 15.02.2017, 07:49:15 ---Und lange Dateinamen unter FAT12/16 gibt es per Definition nicht.
--- Ende Zitat ---
Leider falsch. Lange Dateinamen wurden nachträglich auch FAT12- und FAT16-Dateisystemen beigebracht. Einfacher Test, wenn Du mir nicht glaubst: Eine Diskette (auch heute noch FAT12-formatiert) erlaubt ebenfalls lange Dateinamen unter Windows. Auch unterstützte die allererste Version von Windows 95 noch gar kein FAT32, aber bereits lange Dateinamen, nämlich auf FAT12- und FAT16-Dateisystemen.
--- Zitat von: https://de.wikipedia.org/wiki/File_Allocation_Table#VFAT ---VFAT (Virtual File Allocation Table) ist eine Erweiterung des FAT-Formats zur Verwendung langer Dateinamen, die auf FAT12, FAT16 und seit dessen Einführung im Jahr 1997 auch auf FAT32 angewendet werden kann.
--- Ende Zitat ---
--- Zitat von: 1ST1 am Mi 15.02.2017, 07:49:15 ---Und FAT32 ist abwärtskompatibel zu FAT16, das heißt, eine FAT32-Partition, die die Größenbeschränkung von FAT16 einhält, ist von einem FAT16-System beschreib und lesbar, es sieht nur die langen Dateinamen nicht.
--- Ende Zitat ---
Auch falsch, FAT32 ist komplett anders und (unabhängig von der Partitionsgröße) natürlich nicht von einem System lesbar, das nur FAT12 und FAT16 beherrscht. Wie sollte das auch gehen, wo sich die Verwaltungsstrukturen vollkommen geändert haben.
--- Zitat von: https://de.wikipedia.org/wiki/File_Allocation_Table#FAT32 ---Alte DOS-/Windows-Versionen (bis einschließlich Windows 95A, Windows NT bis Version 4.0, MS-DOS bis 6.22, PC DOS bis 2000, DR-DOS bis 7.03) können nicht darauf zugreifen.
--- Ende Zitat ---
yalsi:
--- Zitat von: 1ST1 am Mi 15.02.2017, 07:49:15 ---In Windows 95 und später findest du die Referenzimplementierung von FAT32.
--- Ende Zitat ---
FAT32 ist mit dem OEM Release Windows 95 B [4.00.1111 / 4.00.1212 / 4.00.1214 - Service Release 2/2.1] in Windows 95 gekommen. Die Clusternummerierung ist dort 32 Bit breit, was es erlaubt, auch auf grossen Platten kleine Cluster zu erzeugen und damit die Platte effizienter auszunutzen. Aber lange Dateinamen kannte Windows 95 / MSDOS 7 schon von Anfang an, darum ist die Aussage:
--- Zitat von: 1ST1 am Mi 15.02.2017, 07:49:15 ---Und lange Dateinamen unter FAT12/16 gibt es per Definition nicht. Das wurde erst mit FAT32 eingerichtet.
--- Ende Zitat ---
eben falsch- VFAT ist unabhängig von der Breite der Clusteradressen, Dateinamenlänge und Clustergröße haben nichts miteinander zu tun. Bei VFAT kann ein Dateiname sich über mehr als einen Directory-Eintrag erstrecken. Der 1. Eintrag im Directory bekommt einen auf 8 Zeichen gekürzten Namen mit der Tilde und enthält einen Verweis auf den nächsten Directory-Eintrag mit dem Beginn des langen Namens. Der wiederum verweist auf den Fortsetzungseintrag usw. bis alle Zeichen untergebracht sind.
Das praktische daran ist eben gerade, das diese Erweiterung bei FAT12 und FAT16 genauso klappt wie bei FAT32, denn der Aufbau und die Wortbreite im Directory sind unverändert.
Übrigens brachte auch OS/2 Warp 3 lange Dateinamen für FAT16 mit, realisierte das aber anders: Dort erhält jede Datei einen 8.3 Namen und es gibt einen neuen Dateityp, in dem diw lange Namen abgelegt sind. Die Dateisystem-Software sorgt dann für die Anzeige in OS/2, unter MSDOS sieht man nur die 8.3 Namen.
Gruß- Georg B. aus N,
Quelle ua. http://www.winhistory.de/more/win95.htm#win95b
Nervengift:
--- Zitat ---Ich besitze weder Win9x noch NT-10 noch die nötigen Tools noch die Erfahrung, damit umzugehen...
--- Ende Zitat ---
Ich hab auch eine 60 GB Platte im Milan drin, auf der sich nur eine FAT32 Partition befindet. Diese Partition habe ich mit OS 10.10 angelegt (GUID-Patitionsschema, MS DOS Dateisystem womit Apple FAT32 in dem Falle meint). Hintergrund dieser Vorgehensweise war, die Platte mal schnell aus dem Milan rausholen zu können und wieder an einem Mac oder Hacki(ntosh) dranhängen können z. B. über USB, um Daten zu schaufeln. Mit dieser Konstruktion gibt es bei mir weder unter MiNT 1.19.x noch Magic Milan 6.1 Probleme.
Ich hatte auch erst versucht HDDRIVER zum Einrichten der Platte zu nutzen und nur eine FAT32 Partition auf der Platte mit HDDRIVER angelegt, aber damit konnte der Mac nicht umgehen. Ich hatte die Platte nicht gemountet bekommen.
ari.tao:
Mein Dank geht diesmal an @czietz und @yalsi für die Korrektur der falschen Aussagen von 1ST1. Damit ist auch dessen Rat obsolet, daß ich mich nun auch noch mit historischem WinDoof beschäftigen soll.
Die einzige WinDose in meinem Haushalt ist dieser SchleppTop von ASUS hier, auf dem ich diesen Text schreibe und mich, mühsam 1000 Flüche unterdrückend, immer wieder vertippe, ua. wg. dieser absolut unglücklich windoofmäßig positionierten CapsLock-Taste.
Mit dieser meiner SUSA kann ich SD- & CF-Plättle nur als ´Wechselmedien´ nutzen, mit all den Implikationen, die wir anderswo schon besprochen haben.
-------
--- Zitat von: mfro am Mi 15.02.2017, 06:06:57 ---
--- Zitat von: ari.tao am Mi 15.02.2017, 03:51:39 ---
--- Zitat --- Auf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen.
--- Ende Zitat ---
kann ich nur noch mal wiederholen, das auch mir auf FAT32 keine Daten mehr verloren gegangen sind - seit ich die FAT32-Parts. unter MAGX mit Schreibschutz versehe.
--- Ende Zitat ---
Die Weisheit, daß MagiC keinen Fehler beim Schreiben auf FAT32 haben *kann*, weil kein Fehler auftritt, wenn man es *nicht* auf FAT32 schreiben läßt, kann ich nicht wirklich nachvollziehen.
--- Ende Zitat ---
Das steht weder in der von Dir zitierten Stelle noch sonstwo in meinem Text. Bitte halte Dich an redliche Argumente und laß mal die Schmäh- & Verleumdungs-Versuche weg!
Am Ende Deines Beitrags #44 hast Du besseres gebracht. Ich habe mich natürlich auch gefragt, was denn genau in den Tests in #17 kaputt geschrieben wurde. Anscheinend ist in A) der RootSektor (= phys.Sektor 0) überschrieben worden (oder wo sonst steht die Part.-Tabelle?), und in B) möglicherweise der BootSektor (= log.Sektor 0 ?) der Part. R (oder auch bloß deren Root-Directory?) - und das, obwohl bei mir in HDDRIVER der Schreibschutz für _alle_ Root- & Boot-Sektoren immer eingeschaltet ist! Auch HDDR. ist als einer der drei Hauptverdächtigen noch nicht entlastet, genauso wenig wie MAGX und MiNT. Dazu kommt noch, daß nmE. der Crash von A) unter MAGX, der von B) aber unter MiNT passierte. (Bem.: Die Füllung von R geschah immer mit den ´Bordmitteln´ des jeweiligen Desktops, die ja auf das darunterliegende BS rekurrieren, nicht etwa mit der ´GEMDOS-Option´ des KOBOLDs.)
-------
Danke auch für Deinen Beitrag, @Nervengift !
--- Zitat von: Nervengift am Mi 15.02.2017, 12:47:52 ---Ich hatte auch erst versucht HDDRIVER zum Einrichten der Platte zu nutzen und nur eine FAT32 Partition auf der Platte mit HDDRIVER angelegt, aber damit konnte der Mac nicht umgehen. Ich hatte die Platte nicht gemountet bekommen.
--- Ende Zitat ---
Weiß US davon?
-------
Hat schon mal jmd. den Treiber (samt Tools) von PPERA für FAT32 benutzt?
-------
PS: Es wäre auch denkbar, daß es sich beim ´Bösen 3eck´ um ein ´Trilemma´ handelt. Damit meine ich: Je zwei beliebige der drei Beteiligten harmonieren gut miteinander - erst der jeweils Dritte stört die Eintracht!
mfro:
--- Zitat von: ari.tao am Mi 15.02.2017, 16:39:13 ---...
--- Zitat von: mfro am Mi 15.02.2017, 06:06:57 ---
--- Zitat von: ari.tao am Mi 15.02.2017, 03:51:39 ---
--- Zitat --- Auf mehreren Rechnern, teilweise mit CompactFlash-Karten zum Datenaustausch mit dem (Linux-) PC und mir ist seit Jahren keine FAT32-Partition mehr kaputt gegangen.
--- Ende Zitat ---
kann ich nur noch mal wiederholen, das auch mir auf FAT32 keine Daten mehr verloren gegangen sind - seit ich die FAT32-Parts. unter MAGX mit Schreibschutz versehe.
--- Ende Zitat ---
Die Weisheit, daß MagiC keinen Fehler beim Schreiben auf FAT32 haben *kann*, weil kein Fehler auftritt, wenn man es *nicht* auf FAT32 schreiben läßt, kann ich nicht wirklich nachvollziehen.
--- Ende Zitat ---
Das steht weder in der von Dir zitierten Stelle noch sonstwo in meinem Text. Bitte halte Dich an redliche Argumente und laß mal die Schmäh- & Verleumdungs-Versuche weg!
--- Ende Zitat ---
Sowas liegt mir fern.
Ich möchte jetzt mit dir aber nicht über das Zitat streiten (das man m.E. nicht anders interpretieren kann), sondern lieber was Sinnvolles tun. Deshalb habe ich - wie von dir vorgeschlagen - deinen Screenshot nochmal studiert.
Dort ist zu sehen, daß HDDRIVER einen Startsektor einer Partition anzeigt, der um eins vom bei mkfatfs angezeigten Dateisystembeginn abweicht (ich nehme an, das ist, was Du uns damit zeigen wolltest?).
Lustigerweise ist es so, daß mkfatfs lediglich XHInqDev2() aufruft und den Rückgabeparameter für den Dateisystembeginn unverändert anzeigt. *Beide* Informationen stammen also letztendlich direkt und ungeschminkt von HDDRIVER (der sich ja bei MiNT als für das Dateisystem zuständig angemeldet hat).
Ich gehe schlicht davon aus, daß das so richtig und gewollt ist und habe mich beim ersten Betrachten auch gar nicht gewundert. XHDI zählt den Bootsektor nicht zum Dateisystem, also startet das gefälligst einen Sektor später. Einen Fehler kann ich da nicht erkennen. Oder hat es mit dem Screenshot eine andere Bewandtnis?
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln