Hallo Besucher, der Thread wurde 1,1k mal aufgerufen und enthält 4 Antworten

letzter Beitrag von abraXxl am

16 Zeichen Dateiname

  • Hi,


    Ich nutze meine SD2IECs immer mit folgenden Einstellungen:
    @XE4
    @XE+
    @XI1


    Aus der SD2IEC Readme dazu:


    Auf meinen SD Karten haben dann alle Datein, die nicht Diskimages sind die Endungen PRG,SEQ, ... um die slelbe SD-Karte auch _gut_ mit meiner 1541U2 nutzbar zu haben.


    Ich habe folgendes Problem festgestellt: Mit obigen Einstellungen gibt es unerwartet Effekte mit Files mit mehr als 12 Zeichen im Filenamen.


    z.b.
    Mit einem frisch gestartem C64 und SD2IEC mit obigen Einstellungen als #8 passiert folgendes:


    Schaut man sich das Directory an sieht man, dass die Dateinamen verstümmelt sind. Vermutlich da die sd2iec-FW feststellt das die Dateien mit Endung länger als 16 Buchstaben und die FW nimmt dann den Short-FAT 8.3 Filenamen mi "~".


    Ist das so gewollt?


    cya

  • @XE4
    @XE+


    *schauder* Uaah... Eigentlich halte ich es für eine grundsätzlich schlechte Idee, einen Teil eines Dateinamens vor dem Benutzer zu verstecken, allerdings ist das Feature auf dringenden Wunsch eines Einzelnen (der es auch implementiert hat) drin.


    Zitat

    Ich habe folgendes Problem festgestellt: Mit obigen Einstellungen gibt es unerwartet Effekte mit Files mit mehr als 12 Zeichen im Filenamen.
    (....)
    Ist das so gewollt?


  • Ich finde dieses Feature praktisch, da die 1541U2 quasi Aktionen an Dateiendungen bindet, ich aus finaziellen Aspekten aber nur eine 1541U2 habe und daher auch gerne das SD2IEC nutze. Ständiges Umstecken ist ja auch nicht gut für alte Hardware.
    Und da sind die Endungen dann störend. Zwei Game-Repositories zu pflegen für 1541U2 und SD2IEC ist blöd, wegen Mehraufwand und Redundanz.


    Ich interpretiere aus deiner Aussage, das du interesse hast, den Bug oder das Feature zu entfernen. Die Motivation ersteres zu erledigen, wirst du also an den Kunden auslagern wollen, der dies schon Implementiert hat. Letzeres würde im Notfall eintreten.


    Ich bin für ersteres und würde gerne mal schauen ob ich nicht den Fehler fixen kann. Ich weis aber noch nicht genau wo?
    Nach "grep -ril XE *" im SD2IEC-Tree würde ich in den fileops.c oder dirops.c suchen wollen. Kannst du genaure Tipps geben? (Die Datein sind lang ... und ich kenn den Code nicht.)


    cya

  • Ich interpretiere aus deiner Aussage, das du interesse hast, den Bug oder das Feature zu entfernen.


    Ja, ich kann allerdings nicht sagen wann ich dazu kommen werde.


    Zitat

    Ich bin für ersteres und würde gerne mal schauen ob ich nicht den Fehler fixen kann. Ich weis aber noch nicht genau wo?


    Ich würde wohl bei fat_readdir in fatops.c anfangen.


    Zitat

    Nach "grep -ril XE *" im SD2IEC-Tree würde ich in den fileops.c oder dirops.c suchen wollen.


    Die Kommandos werden zeichenweise mit einigen switch-Konstrukten in doscmd.c ausgewertet. fileops.c sind die "generischen" Dateioperationen, die immer verwendet werden und über per-Partitions-Funktionspointer (siese wrapops.h - ist nicht schön, sparte aber gerade auf dem ATmega32 kritisches Ram) die von den verschienenen Dateisystemen (FAT/M2I/Dxx) implementierten Operationen wie z.B. readdir aufruft. Da der von readdir zurückgegebene Name sowohl für das Directory als auch das Laden der einzig maßgebliche ist bietet es sich bei diesem Bug als Startpunkt deutlich an.


    Bah, beim Tippen der Erklärung habe ich das Problem schon gefunden und gefixt...