Autor Thema: Fehler im GEMDOS  (Gelesen 247 mal)

0 Mitglieder und 2 Gäste betrachten dieses Thema.

Offline Count

  • Benutzer
  • Beiträge: 266
Fehler im GEMDOS
« am: Mi 06.05.2026, 15:04:30 »
Ist der GEMDOS-Bug, dass Pfadangaben keine doppelten Backslashes enthalten dürfen, bekannt? Ich habe nirgendwo etwas darüber finden können. Wenn versucht wird, mit Fopen eine Datei zu öffnen, und in der Pfadangabe doppelte Backslashes verwendet werden, wird diese Datei nicht gefunden und Fopen liefert EFILNF zurück.

Dabei scheint es egal zu sein, an welcher Stelle im Pfad bzw. bei welcher Verzeichnisbaumtiefe der doppelte Backslash vorkommt.

Getestet habe ich das ganze mit Hatari und TOS 3.06, 2.06, 1.04 und KAOS (14121990) sowie auf meinem MegaSTE mit TOS 2.06. Im Emulator tritt der Fehler übrigens nicht bei GEMDOS-Laufwerken auf, sondern nur bei Festplatten- (und vermutlich Disketten-) Images.

Hier ein kleines Beispiel in GFA-Basic:
path$="C:\\NEWDESK.INF"+CHR$(0)
pathaddr%=VARPTR(path$)
handle%=GEMDOS(61,L:pathaddr%,0)
IF handle%<0
  PRINT "Fehler ";handle%
ELSE
  VOID GEMDOS(62,handle%)
ENDIF

Passend dazu liefert fopen() in C natürlich einen NULL-Pointer:
#include <stdio.h>
#include <errno.h>

int main()
{
    FILE *fp = fopen("C:\\\\NEWDESK.INF", "r");

    if (fp == NULL) {
        printf("Fehler %d\n", errno);
    } else {
        fclose(fp);
    }

    return 0;
}
« Letzte Änderung: Mi 06.05.2026, 15:31:51 von Count »

Offline kernal

  • Benutzer
  • Beiträge: 181
Re: Fehler im GEMDOS
« Antwort #1 am: Mi 06.05.2026, 16:05:08 »
Wieso sollte das ein Fehler sein? Zwei Pafdtrenner direkt hintereinander ergeben keinen Sinn. Die Aufrufparameter sind Fehlerhaft. Da Pfadangaben heutzutage leider häufig lasch gehandhabt werden, tolerieren viele moderne Betriebssysteme dieses Fehlverhalten. Daher funktioniert das höchstwahrscheinlich im Emulator auch mit GEMDOS-Laufwerken - ich nehme an, der Emulator reicht den Pfad ungeprüft an das Host-OS weiter und überlässt dem die Prüfung.

Offline AndreasKromke

  • Benutzer
  • Beiträge: 224
Re: Fehler im GEMDOS
« Antwort #2 am: Do 07.05.2026, 11:21:59 »
Besser Fehlerhaft als Einzelhaft.  ;D

Im übrigen ist GEMDOS im wesentlichen ein MSDOS-Klon. Wenn Dein Programm mit MSDOS funktioniert, mit GEMDOS nicht, könnte man das als Fehler in GEMDOS bezeichnen, aber erstens gibt es niemanden, beim dem Du Dich beschweren kannst, und zweitens ist es irrelevant, denn Dein Programm sollte ja auf GEMDOS laufen, und das ist dann Dein Problem. Es wäre auch wenig hilfreich, EmuTOS entsprechend zu verbessern, weil dann Dein Programm auch nur in EmuTOS liefe, aber wenn Du möchtest, kannst Du ja mal mit den Quellen von EmuTOS rumspielen.

Offline goetz @ 3rz

  • Benutzer
  • Beiträge: 2.249
Re: Fehler im GEMDOS
« Antwort #3 am: Do 07.05.2026, 12:35:14 »
Die Atari-GEMDOS-Doku von 1986 sagt nichts zu mehreren Backslashes hintereinander. Das Profibuch schreibt auf Seite 160 von einem Backslash zwischen Bestandteilen eines Pfads. Es warnt auch davor, dass GEMDOS fehlerhaft sei, relative Pfadangaben aufzulösen und dass man das besser selbst machen sollte.

Man kann durchaus argumentieren, dass man mit mehreren Backslashes rechnen können sollte, dass das kein exotischer Sonderfall sei. Allerdings ist die heutige Realität am Atari halt die, dass dein Programm besser auf TOS 1.04 aufwärts laufen sollte, besser noch auch mit TOS 1.0 und 1.02.

Das hindert einem nicht daran ggfs moderne Implementierungen zu verbessern, bei denen der Source vorliegt. Aber ein doppel-tripel-Backslash wäre es mir nicht wert, nicht mehr auf TOS 1.x laufen können.
Wider dem Signaturspam!

Offline Count

  • Benutzer
  • Beiträge: 266
Re: Fehler im GEMDOS
« Antwort #4 am: Heute um 18:35:38 »
Ich habe meiner Software eine Dateipfadbereinigungsfunktion verpasst. Gefährlich wird das Verhalten von GEMDOS, wenn man mit so einer Pfadangabe ein Verzeichnis anlegen will. Dann erhält man nämlich eine Kaskade von namenlosen Ordnern, die so tief verschachtelt ist, dass sie sich vom Desktop aus nicht mehr löschen lässt. Mit Kobold ist das löschen aber trotzdem möglich.

Das beigefügte Programm TEST.TOS zeigt die Auswirkungen. Es versucht, einen Ordner "\\TEST" anzulegen. Bitte nur ausführen, wenn Kobold zur Verfügung steht, oder auf einer leeren Diskette, die anschließend formatiert werden kann.