Software > Alternative Betriebssysteme

MAGX´ Macken

<< < (23/27) > >>

ari.tao:

--- Zitat von: mfro am Fr 10.03.2017, 10:27:33 ---
--- Zitat von: ari.tao am Fr 10.03.2017, 10:20:14 --- wäre das imho ein Fehler entweder in MAGX oder in MiNT! (Habe ich unregelmäßig abwechselnd benutzt).
--- Ende Zitat ---
Da würde ich widersprechen. Meiner Ansicht nach wäre es ein Fehler, wenn in einem Unterverzeichnis vorhandene, versteckte Verzeichniseinträge (das sind LFNs) _nicht_ kopiert würden. Wenn ich einen Ordner von a nach b kopiere, erwarte ich, daß der gesamte Inhalt kopiert wird.
--- Ende Zitat ---
Dagegen würde ich erwarten, daß ich eine Wahlmöglichkeit angeboten kriege.


--- Zitat von: mfro am Fr 10.03.2017, 10:27:33 ---
--- Zitat von: ari.tao am Fr 10.03.2017, 10:20:14 ---Aber wenn es denn solche Reste sind - wie kann ich sie los werden?
--- Ende Zitat ---
Die Einträge, die ins Nirwana zeigen, kriegst Du mit dosfsck weg. Die gültigen werden dabei aber stehen bleiben. Wenn's FAT12 oder 16 ist, könnte CHKDSK3 von Atari evt. helfen?
--- Ende Zitat ---
Nein, auf meinen FAT16ern habe ich so etwas immer gleich gelöscht, sowie ich das bemerkt habe.
Werde heute Abend mal auf die Suche gehen.
Erst einmal vielen Dank für die Hilfe!
Das sich das so vererbt, da wäre ich noch lange nicht drauf gekommen.

mfro:

--- Zitat von: ari.tao am Fr 10.03.2017, 10:52:15 ---Dagegen würde ich erwarten, daß ich eine Wahlmöglichkeit angeboten kriege.

--- Ende Zitat ---

Alles, was das nicht-VFAT-fähige OS zu sehen bekommt, sind versteckte, allerdings aus "nicht-VFAT-Sicht" sehr wohl gültige Verzeichniseinträge. Willst Du, wenn Du einen Ordner von a nach b kopierst, für jede einzelne Datei gefragt werden, ob Du die wirklich kopieren willst?

Das Problem ist die VFAT-Spezifikation. Typisch MS-halbgar, aber geschickt so gemacht, daß es so aussieht, als ob der Fehler bei "den anderen" läge.

ari.tao:
Die Suche verlief negativ! Keine Überreste von LFNs auf den fraglichen Parts., auch nicht ´hidden´! Auch dieses Rätsel ist weiterhin offen...
Ich habe es gewagt, dosfsck -a -V x: mit x = M, N aufzurufen (diesmal unter MiNT). Ergebnis -> Anhang. Der dritte Lauf war eine Wiederholung des zweiten und dauerte _deutlich_ länger - wieso eigtl.? Was hat denn dosfsck verändert?
Daß die Anwendung auf die 1,8GB-Part. am angeblichen Speichermangel scheitert, hatte ich ja schon geschrieben.
Kann schon sein, daß uns KleinWeich da wieder Mist angedreht hat. Aber im Moment sind die hier aus dem Schneider. Wenn ich vom Tausch-Medium Daten ´runterkopiere, bleibt von LangNamen immer bloß eine Tilde ´~´ übrig. Auf den Parts. M & N sind überhaupt keine solchen, auch keine ehemaligen; das Material stammt ausschließlich von uralten BackUps aus Zeiten, als es noch keine LangNamen auf dem Atari gab.
Was ist denn Start (2) überhaupt?

1ST1:
Der 8.3 Dateiname mit der Tilde wird unter Fat32 und NTFS automatisch erzeugt, denn das ist der Kurzname, den Betriebssysteme ohne LFN-Support zu sehen bekommen. Das funktioniert sogar unter Windows 10 64 Bit noch. "cd c:\progra~1" wechselt nach "c:\programme" (bzw "c:\program files") und "cd c:\progra~2" wechselt nach "c:\programme (x86)" (bzw "c:\program files (x86)"). Die heilige Kuh der Kompatiblität, selbst wenn unter 64 Bit Windows keine 16 Bit Programme mehr laufen.

Und nein, MS-DOS bzw. Windows machen auf einem FAT-Laufwerke (normalerweise) keinen Fehler. Wäre ja noch schlimmer, bei der Verbreitung heutzutage. Der Fehler muss entweder in MiNT (glaube ich weniger, da Open Source und Tausende Anwender haben da schon in den Code reingesehen) oder MagX sein. Deine Behauptung wäre ja als ob sich Erdogan als einen lupenreinen Demokraten bezeichnen würde.

ari.tao:
^^-- Kaum bist Du da, schon riecht´s wieder nach Schwafel,  >:D !
Wir bewegen uns gerade nicht auf Deiner geliebten WinDose, sondern auf dem Atari, und da können auch MAGX & MiNT Tilden aus LangNamen erzeugen - aber wie ich oben deutlich ausgeführt habe, gibt es auf den im ScreenShot sichtbaren Parts. keine Überreste von LFNs, also auch keine Tilden. Der neu zu Tage geförderte Fehler ist daher imho höchstwahrscheinlich keiner in MAGX oder MiNT, sondern bloß einer in dosfsck, wie die drei Buchstaben LFN in den obersten Zeilen in den MiniWin-Fenstern im ScreenShot anzeigen: Offensichtlich glaubt dosfsck zu Unrecht, daß es sich um LFN-Parts. handelt. Eine minder wahrscheinliche Möglichkeit wäre noch, daß HDDRUTIL da ´was falsch eingerichtet hat - jedoch wurde die Part. M zwischendurch mit mkfatfs behandelt (mit bloß zwei Recs./Cluster, deshalb die große Cluster-Anzahl => 19MB mehr!), das hätte also korrigiert sein müssen (außer, wenn auch mkfatfs da was falsch macht). Das wäre also ein weiterer Fall für unsere MiNTzer, aber weit wichtiger wäre es, den Speicherbedarf von dosfsck zu reduzieren. So, und nun geh mal wieder

--- Zitat von: 1ST1 am Sa 11.03.2017, 21:35:28 ---Die heilige Kuh der Kompatiblität
--- Ende Zitat ---
hüten oder noch besser, Ziegen bei

--- Zitat von: 1ST1 am Sa 11.03.2017, 21:35:28 --- ...Erdogan...
--- Ende Zitat ---
denn Erdokhan braucht ja dringend neues Personal.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete