möchte eine neue Funktion vorstellen (noch nicht auf dev, noch in der finalisierung):
Problem: durch den Komfort von aktuellen Dateisystemen, haben immer wieder Dateien Sonderzeichen im Namen, die auf Fat32 einfach nicht erlaubt sind. Z.B. „?“ oder „:“ sieht man immer wieder.
Aktuell scheitert der Upload dann einfach.
Daher folgende Lösung:
Beim Zugriff auf das Filesystem ersetzen wir die Sonderzeichen durch eine URL-Codierung (z.B. wird „?“ zu „%3F“). Wenn wir auf Dateinamen zugreifen, wandeln wir es wieder zurück.
Habe das im FTP und Espuino so eingebaut und es scheint sehr gut zu funktionieren.
Gerne mal ausprobieren und Feedback geben, wenn ihr Lust habt.
Ich benutze kein FTP, deswegen habe ich nur mal drübergeschaut und mit der KI diskutiert - der PR ist auch eine Nummer zu Groß für mich
Ich habe dir meine Chatgpt-Konversation angehangen.
Es sollten folgende Punkte noch einmal angesehen werden (ich weiß die KI ist nicht die Allheillösung aber mittlerweile besser als ich):
Laut der KI wird SanitizedFS::open(const String&) doppelt encodiert
die reparse() verändert auch Dateinamen, welche auf anderem Weg auf den ESPUINO gekommen sind - dann wird aus folgender Datei a%2Fb.mp3 das da mit Pfadtrenner a/b.mp3
Die KI hatte noch eine Performanceverbesserung zu const String illegal_chars = ":*?\"<>|%";
Der SPI-SD-Pfad könnte brechen, dass muss man wahrscheinlich noch mal genauer betrachten (würde nur lolin_d32_pro betreffen)
Das \ Backslash und DEL 0x7F sollte noch behandelt werden. Folgende sind wahrscheinlich unkritisch #, &, +, ;, =, Leerzeichen
Vielen Dank!
Das mit den zweiten Open ist tatsächlich ein Bug den ich übersehen habe.
Und das Pauschale reparsen lässt wirklich die Sonderfälle noch übrig. Das könnte man mutwillig ausnutzen.
Backslash ist bewusst nicht drin, da das für Pfade gilt, genauso wie slash. Und es geht hier nicht pauschal um Sonderzeichen (die können wir) sondern um die Limitierungen von Fat32, die ein unerfahrener User nicht erwartet.
Alles was nicht behandelt wird, wird weiterhin vom filesystem einfach abgelehnt.
Das mit dem Spi-SD halte ich für falsch, das sollte so sauber funktionieren.
Ich schau nochmal drüber und werde zumindest 1) und 2) noch fixen
Im ursprünglichen SdCard.cpp existiert im Nicht-SD_MMC_1BIT_MODE-Zweig SPIClass spiSD(HSPI); und fs::FS gFSystem = (fs::FS) SD;. Im PR wird daraus #define HARDWARE_FS SD und SanitizedFS gFSystem(HARDWARE_FS);; die SPIClass spiSD(HSPI);-Definition ist im Diff nicht mehr sichtbar, während spiSD in SdCard_Init() weiterhin benutzt wird.
Das sollte unbedingt für alle PlatformIO-Umgebungen geprüft werden, nicht nur für SD_MMC. Falls spiSD nicht anderswo definiert ist, bricht mindestens der SPI-SD-Build.
.
.