Forums

Oke, dat moet ik gemist hebben.

Verder is er nog verplaatsen dat niet ging, maar weet niet meer of er een crash op volgde.  Zal dit nog even testen - maar dat zal niet meer voor vandaag zijn.

En ook afspelen ging niet, maar hier crashte ie niet op.

Willy

Heeft geen haast. Geef maar een gil als je weer ergens tegenaan loopt.

Getest met verplaatsen.  Geen probleem.

Je krijgt de melding:  No such file.

Wat prima is.

Willy

Mooi, bedankt voor de terugmelding. Ik hoor het wel als je nog ergens een crash tegenkomt.

Willy & parasol:

Het zou heel makkelijk zijn om alle tekens zodanig te strippen dat er alleen nog maar ASCII printables overblijven. Heb je je ook gerealiseerd wat je dan krijgt? Bij ons in NL zul je het verschil waarschijnlijk niet eens merken. Maar zodra er diacritische tekens in de filename voorkomen, dan krijg je in plaats van die tekens complete garbage. Ik weet niet of dat echt een vooruitgang is. Dan komt er ook nog bij dat niet alle encoding byte-oriented zijn. Neem UTF-8, dat kan 1 tot 4 bytes per teken lang zijn afhankelijk van het codepoint. Neem UCS-16, wat Microsoft gebruikt op NTFS, dat is altijd twee bytes. Als je daar willekeurig bytes in gaat veranderen, weghalen of toevoegen, dan het he-le-maal fout, wordt een complete bende. Krijg je ook allemaal combinaties die geen geldige codepoints opleveren en wat de implementatie daarmee doet moet je maar zien.

En dan komt weer, wat ik al twee keer eerder noemde, op een FAT filesysteem weet Linux niet wat voor encoding ("code page") is gebruikt. Dat zou dus een byte-oriented encoding kunnen zijn (iso-8859-1 of windows western), maar het zou ook een "wide" encoding kunnen zijn als UCS-16 of een multibyte encoding als UTF-8.

Dat is dus hoe dan ook, linksom of rechtsom vragen om problemen. Op een FAT filesysteem zou je echt eigenlijk alleen ASCII tekens moeten gebruiken.

Uiteraard heb ik me dat gerealiseerd maar over de andere kant:

De vraag is of de gebruiker het interesseert hoe de file precies heet. De naam van de file en de getoonde omschrijving aan de gebruiker hoeven niet eens overeen te komen.

De overlast van een crash of het niet kunnen verwijderen of verplaatsen van files is nl veel groter.

Iemand die op file niveau met opnames bezig is kan ultimo altijd nog zelf de filename aanpassen.

Hierdoor wordt het image echter wel veel robuster en werkt prettiger voor de meerderheid.

De image zelf heeft al de optie (config.recording.ascii_filenames) om de filename te converteren. Alleen staat dat default uit, om de redenen die Erik al noemt (neem een taal als Russisch bv).

Koppel de default waarde aan de door de gebruiker ingesteldde taalinstelling van het image en de ingebouwde ascii file functie zal automagisch goed gebruikt worden toch?

Dit is de translatie die er plaatvind: https://github.com/O...SCIItranslit.py

Die optie vind ik wel mooi ja. Ik heb 'm aan staan. Maar zolang je niks gaat doen met USB sticks heen en weer sjouwen of verbindingen maken met Windows machines (SMB, FTP) is het helemaal niet nodig, ext4 van je interne harddisk of NFS hebben er totaal geen moeite mee, die zien alles als UTF-8.

Een crash mag in principe nooit voorkomen, met parasol eens, maar zodra je encodings van verschillende lengtes of multibyte gaat combineren kunnen er dingen héél erg mis gaan. Dan nog zou het niet mogen crashen, maar is wel lastiger te vinden en te fixen, dat kan dan ergens diep in een library staan.

[rant]

Ik ben nog "opgegroeid" in een wereld waar alles ASCII en Engels was en dan had je dit soort problemen nooit. Nu moet alles vertaald zijn, tot aan het Friese dialect wat in Joure gesproken wordt en iedereen vindt het normaal dat dat allemaal altijd 100% werkt en dat daar allemaal moeite voor gedaan moet worden.

[/rant]