Microchip MDD. Problem med filnamn.

[SeniorLemuren]

Strängen är korrekt formaterad med avslutande NULL.
Har även gjort en egen funktion konvertera både int's till strängar och en egen funktion för att "NULL-padda" filnamnen.

Du säger att strängen är korrekt formaterad, min fråga är hur har du kollat det. Enda sättet för att vara säker på att "loop_filename_string" är rätt formaterad torde vara att loopa ut alla ascii-värden som finns i strängen och kolla så att det verkligen inte kommit med något ej godkänt värde. Att skriva ut strängen som en textsträng för att kolla att den är ok. funkar inte.

[TomasL]

FAT32 och långa filnamn är två helt skilda saker, och har inte med varandra att göra.
Vidare, om man läser AN1045B (vilket jag tror är den senaste)

UNSUPPORTED FEATURES
Long filenames are not supported

LFN på FAT kräver VFAT för att kunna fungera, vilket MDD garanterat inte stöder, dessutom vill jag minnas att MS inte släppt VFAT/LFN, utan man får betala för att få använda det.

[sodjan]

OK. Då återkommer vi till frågan om det vettigt att allokera
512 bytes för variablen för filnamn.

[TomasL]

Att tillägga, filnamnet på en DOS partition är alltid 8.3, LFN lagras i en gömd struktur, så jag vill påstå att TS är lite fel ute.

Sodjan, det räcker med 11(12) bytes.

[Icecap]

Faktisk kan et filnamn inkl. path vara på upp till 128 tecken under DOS om jag inte minns fel, under Win är gränsen 512 tecken.

Men 12 tecken + 1 stopp räcker om man inte ska ha underbibliotek. (8 + punkt + 3 = 12 tecken)

[TomasL]

Helt riktigt, dock är filnamnet alltid 8+3 oavsett om det är FAT12, FAT16 eller FAT32.
Även i VFAT dvs LFN så är filnamnet alltid 8+3, det långa filnamnet är som sagt enbart ett tillägg, vilket lagras separat.

[Zajber]

Men för guds skull, jag har ju inte ens 3 tecken innan det hänger sig!

Dessutom kan jag fortfarande skriva långa filnamn hur bra som helst utan siffror!

[sodjan]

Och hur fungerar det med en mer rimlig loop_filename_string ?

[SeniorLemuren]

Men för guds skull, jag har ju inte ens 3 tecken innan det hänger sig!

Dessutom kan jag fortfarande skriva långa filnamn hur bra som helst utan siffror!

Det är just därför jag frågar dig om du verkligen har kollat strängen i verkligheten. Ponera att det inte funkar med omvandlingen mellan heltal till ascii som du tänkt dig och att du skickar värdet 1 och värdet 4 i stället för HEX31, HEX34 i filnamnet när du vill skicka 14 eller att det t.ex. smiter med ett otillåtet tecken i omvandlingen.

Om det ska gå att spara långa filnamn (vilket jag inte är säker på) så borde det ju rimligen vara fel på filnamnsformatet.

[Zajber]

Det är just därför jag frågar dig om du verkligen har kollat strängen i verkligheten.

Jag har kontrollerat alla strängarna fram och tillbaka med ICD3:an.

[TomasL]

Vad menar du med "kontrollerat med ICD3"?

Börja med att sättat filnamnslängden till den supportade längden, dvs 8+3.
Du kan INTE använda långa filnamn i ett FAT-system, det är totalt och fullständigt omöjligt.

Därefter får du väl börja singelsteppa, en bra ide är att använda en serieport på målprocessorn, och skicka debuginformation till ett terminalprogram.

En annan sak, du bör lägga in en funktion som hanterar "General Exeption", då kan du få en hint var det spårar ut.

[TomasL]

Vilken version av MDD använder du, och hur har du konfigurerat det.

Verkar som att man från 1.30 har en viss LFN och UTF16-support.
Dock kan man INTE göra så som TS skrev i första inägget.

[Zajber]

Verifierat med ICD3 innebär att jag singelsteppar mig genom konverteringen av filnamnen och kontrollerar detta under watch-listan. Där jag ser både tecknet som ligger på sträng-posen och hex-talet för det aktuella tecknet. Där alla strängarna har korrekta teckenföljder med avslutande NULL.

Versionen av MDD är 1.3.6

ALLOW_LFN är definierad.

Jag vet att man i exemplet inte kör med FSfopen utan med wFSfopen (har inte koden tillgänglig just nu, kommer inte ihåg funktionsnamnet exakt i huvudet). Men det hjälper inte om jag kör med deras exempel med NULL-paddade filnamn eller med FSfopen som jag gör nu där jag slipper padda strängarna med NULL på vartannat tecken.

Och bara för att tillfredställa detta eviga behov av att korta ner strängarna har jag testat att korta ned dessa till bara några tecken utan någon som helst skillnad, vilket det inte heller ska vara då jag endast just nu använder de första tre-fyra tecknen av strängen som alltid i sedvanlig ordning avlutats med ett 0x00.

[TomasL]

FSOpen tillåter enbart 8.3 i ascii, inget annat.
Skall du använda LFN/16 så är det den andra funktionen som gäller.
Sedan innebär normal felsökning alltid, back to the bones.
Detta sk "eviga behov" underlättar felsökning.

[Nerre]

Kan inte problemet var så enkelt att det går att spara långa filnamn men att biblioteket inte stöder dublettkontroll på mer än 8+3?

D.v.s. problemet uppstår när de 8 första tecknen i filnamnet inte är en unik kombination.

Fast om filerna heter "Day_1.txt" till "Day_30.txt" så stämmer ju inte den teorin heller...

Men om du provar att döpa dem till "day01.txt" till "day30.txt"? D.v.s. lika långa filnamn, inga specialtecken eller versaler.