Linus Torvalds kifejezte gyűlöletét a case-insensitive fájlrendszerek iránt

Fájlrendszer, NAS, storage

Linus Torvalds az LKML-en írta meg az érzéseit a file-system case folding-ról a case-insensitive fájlok/mappák kapcsán:

[...]

"Az egyetlen tanulság az, hogy a fájlrendszeres emberek soha nem tanulnak.

A case-insensitive nevek borzalmasan rosszak, és egyáltalán nem lett volna szabad megcsinálni őket. A probléma nem a tesztelés hiánya volt, hanem az, hogy egyáltalán megvalósítottátok.

A problémát aztán tovább súlyosbítja az, hogy "megpróbáljátok jól csinálni", és ennek során borzalmasan rosszul csináljátok, mert "jó" nem létezik, de a próbálkozás során véletlenszerű bájtoknak mágikus jelentése lesz.

És egyébként, a tesztek is teljesen hibásak. Utoljára, amikor láttam, nem is tesztelték az igazán érdekes eseteket – azokat, amelyek user space-ben biztonsági problémákat okoznak.

Biztonsági problémák, mint például: "a user space ellenőrizte, hogy a fájlnév nem egyezik valamilyen biztonság-érzékeny mintával". És aztán a shit-for-brains fájlrendszer mégis egyezteti azt a mintát, mert azok az emberek, akik case-insensitivity-t csinálnak, MINDIG olyan dolgokat tesznek, mint a nem nyomtatható karakterek figyelmen kívül hagyása, tehát most a "case insensitive" azt is jelenti, hogy "más dolgokra is érzéketlen".

Példákért lásd ezeket a commitokat: 

5c26d2f1d3f5 ("unicode: Don't special case ignorable code points")

és

231825b2e1ff ("Revert 'unicode: Don't special case ignorable code points'")

és sírj.

Tipp: ❤ és ❤️ két unicode karakter, amelyek csak ignorálható kódpontokban különböznek. És mit gondolsz? Azok az inkompetens emberek, akik azt akarják, hogy ezek ugyanolyannak számítsanak, akkor más véletlenszerű – és esetleg biztonság-érzékeny – fájlok is ugyanolyannak számítanak, csak mert ignorálható kódpontokat tartalmaznak.

Így most minden egyes user mode program, amely ellenőrzi, hogy nem nyúl speciális utakhoz, gyakorlatilag átverhető, hogy megtegye azt, amit kifejezetten ellenőrzött, hogy ne tegyen. És nem, ez nem valami ritka dolog. Rengeteg program pontosan ezt csinálja.

A francba. A case insensitivity egy HIBA. Nem tudom megérteni, hogy a fájlrendszeres emberek még mindig azt hiszik, hogy ez egy feature. Olyan, mintha annyira imádnák a régi FAT fájlrendszert, hogy muszáj lenne újraalkotniuk – rosszul."

Részletek itt.

(A cikk nyomokban Mesterséges Intelligencia által szolgáltatott adatokat tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)

( Zahy v | 2025. 04. 27., v – 11:27 )

Csak azt tudnám mondani:

"A krumplileves legyen krumplileves!"

Azaz ha egy fájlrendszert már a tervezése során kis-nagybetű érzéketlenre terveztek, akkor az legyen olyan - de ekkor a tervezés során fentieket is figyelembe kell venni. Ekkor talán lehet az implementáció is jó. Ha ezzel szemben már *VAN* egy FS, akkor utólag ráerőszakolni ezt az érzéketlenséget gyakorlatilag kudarcra van itélve. (Amúgy elvi síkon érdekelne, hogy mi van az NTFS-sel, ami tudtommal tud érzékeny is lenni, ha  valahol valaki valamit átállít. Hogy kb. a Winen használt szoftverek 99%-a állna tőle fejre, arra szerintem mérget lehet venni.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Végigszaladtam rajta.

Fenti cikk pont nem a te megjegyzésedet erősíti. Ugyanis az, hogy valamikor később  implementálták az öröklési funkciót arra a nyomorult flag-re (nem pedig az adott flag implementálásával egyidejűleg), azt jelzi, hogy tervezéskor nem érezték fontosnak (ha egyáltalán felmerült) - márpedig ez eléggé alapszolgáltatás lenne egy ilyen eszköznél. (Tudom, hogy sántít mint minden hasonlat, de read-only mount után elvárom, hogy az adott FS minden egyes fájlja és könyvtára gyakorlatilag is RO legyen. Nyilván amikor rácsatolok egy másikat, ott megint szabályozhatom.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ekkor talán lehet az implementáció is jó.

Nem lehet. A kis- nagybetűsítés ugyanis lokalizáció függő, ezért képtelenség hordozhatóra megcsinálni.

Tipikus példa, nálunk a nagybetűs "I" (U+0049) kisbetűs párja az "i" (U+0069), míg pl. egy azerbajdzsáni Windows-on nem, náluk az ugyanis "ı" (U+0131).

Amúgy elvi síkon érdekelne, hogy mi van az NTFS-sel, ami tudtommal tud érzékeny is lenni

Nem tud. Ott a VFS rétegben konvertálják (így lokalizáció függő a végeredmény). Tudtommal az egyetlen, ami jól kezeli, az az exFAT, ami konkrét sok-sok megás kisbetűről-nagybetűre és nagybetűről-kisbetűre leképezőtáblákra pazarolja az értékes tárhelyet (igen, az összes partíción elpazarolja). Ez ezért "jó", mert bár így a kisbetűsítés lokálizáció független, viszont így esélyed sincs helyesen beírni egy magyar Windows-on azt a fájlnevet, amiben "i" betű van...

( Raynes v | 2025. 04. 27., v – 12:11 )

Linus-nak megint igaza van. A case sensitive fájlrendszer több gondot okoz, több komplikáltabb eset leprogramozását igényli, mint amennyi gondot megold. Igazából ezt a VFS-ben kéne implementálni, úgy jó lenne korlátokkal bármilyen fájlrendszerben. De jobb az ilyet nem használni. Értem, sok normi össze-vissza mentegeti a Fájl, fájl, FÁjl, stb. hülyeségeit, és nekik könnyebbség, ha a gép kitalálja helyettük, hogy mire gondolt a költő, de szépen ők is meg tudják szokni, hogy ezek a *nix rendszerek ilyenek, hogy figyelni kell a kis-nagybetű különbségre. Kényelmetlenség, de pár nap alatt simán megszokható egy kis fegyelemmel.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A case sensitive fájlrendszer több gondot okoz, több komplikáltabb eset leprogramozását igényli, mint amennyi gondot megold.

Ponthogy fordítva: a case insensitive komplikáltabb, ugyanis azt implementálni a világ nyelveire, hogy mik a kis-nagybetű párok, nem egyszerű. A komplex irásrendszereknél, mint a különféle ázsia nyelvekben, nem olyan egyszerű ez, mint a latin betűs írásoknál.

Például a Hangul írásban nincs külön kisbetű, nagybetű.

Amúgy történelmileg a latin és klasszikus görög írásban sem volt kisbetű, csak nagybetűt használtak. A kisbetűs, minuszkula írás csak azért terjedt el, mert kézírás szempontjából sokkal gyorsabban lehetett így írni, ez a az iratok (oklevelek, Bibilia stb.) másolásánál, lejegyzésénél nagy segítség volt az írnoknak. A görög írásban a 10-ik században jelent ez meg, a latinban meg a negyedik században.

Nem véletlen, hogy a ránk maradt kézzel írt Bibliák nagy része minuszkulával van írva, minden betű kisbetű benne (igen, még a nevek is).

A komplex irásrendszereknél, mint a különféle ázsia nyelvekben, nem olyan egyszerű ez, mint a latin betűs írásoknál.

Szokás szerint hülyeségeket hordasz össze. Az ázsiai írásrendszereknél tök egyértelmű a kisbetűsítés (vagy mert nincs is, vagy mert egy nyelv használja csak, mint a hiragana/katakana/hangul).
Pont, hogy a latinnál nem egyszerű a dolog (amit sok-sok nyelvre húztak rá, mindenki a maga kis csavarjával).

( gelei v | 2025. 04. 27., v – 12:16 )

Persze, de ha nem droidoknak gyártunk oprendszert, hanem hús-vér usereknek, akkor bennem azért felmerül a kérdés, hogy a könyvelés2024.xls és a Könyvelés2024.xls miért kéne, hogy két különböző fájl legyen. Erre még senki nem tudott nekem életszerű példát mondani, de hajrá, itt a lehetőség.

A Linux fontos tervezési elve a minél kényelmesebb az OS programozóinak, annál jobb hozzáállás.  Rengeteget rendszer terveztem Linux alapokon, nagyon sok produktív rendszerben termel nekünk pénzt - szerver oldalon. IT-hoz nem értő hús-vér usereknek soha nem telepíteném, mert ők nem fogják megérteni soha, miért kezeli a példádat két fájlként, pedig programozóként nagyon is helyeslem, hogy az két külön fájl.

Nem a case sensitive fájl rendszer szokott problémát okozni (mert abban egyféle fájlnév egyféle fájlnevet jelent) hanem a case insensitive. 

De gyakorlati példa: Próbálj meg pl egy hatalmas kódbázist migrálni pl kódtárat, commitról commitra egy case insensitive fájlrendszerben. Garantáltan belefutsz valamibe, ami a végén nem lesz jó. Névkonvenciók meg nem véletlen vannak.

A case insensitive fájlrendszer szerintem felesleges kavarás. Szerintem ez user szinten is előjöhet, inkább hátrány.

Ok, akkor átgondolom, és sorolom:

Én életem során kb háromszor szívtam ilyesmivel (amire emlékszem is). Szerintem az SVN->Mercurial migráció, Mercurial->Git migráció, és SVN->Git migráció volt. Adott volt a környezet, valószínűleg valami rosszul is volt beállítva (legalább egy kis ideig, amíg rájöttek), és Windows-ról commitoltak az emberek. Cross platform problémák jöhetnek elő.

Az egyik user becommitolja a jozsi.cpp-t, a másik a Jozsi.cpp-t, mindkettő felmegy. Amikor a windows-os user ezt le akarja szedni, akkor hibát fog kapni. Rájönnek, valahogy javítják. Majd valamilyen eszközzel két év múlva migrálni akarod ezt a kódtárat, és az az eszköz is szétszáll rajta. Commitról commitra, change-ről change-re megy.

Vagy másik kérdés: Programozóként ha egy kódba beleírja valaki azt, hogy require('Config.js'), akkor a fájlrendszerben ne config.js legyen már, mert ez kb olyan érzés, mintha a változók is case insensitive-ek lehetnének. Ez már keresztbe tesz a névkonvencióknak is, tök mást jelent leírva ez. vagy az. Egyébként is van elég trehány programozó, még csak az kellene, hogy mindegy, hogy írják a fájlneveket.

  • MyClass - osztálynév,
  • myMethod() methodusnév,
  • userName változónév
  • MAX_SIZE konstans.

Csak példák a névkonvencióra, nem jelent gondot, ha a fájlnevekben sincs keveredés. A gondot az jelenti, ha máshogy írva is megtalálja a fájlt egy rendszer, egy importkor.

Ilyen miatt utána szétszáll CI/CD pipeline is, konténerben is lehet problémád, volume mountolás, stb...

Éppen ezért fejlesztői szemszögből: ami kisbetű az kisbetű legyen, ami nagybetű az nagybetű. Az összes többi kavarás (amivel konkrét problémákba fut bele minden fejlesztő, ha nem is naponta, de az évek alatt többször)

Az ilyenekből adódnak azok a problémák, hogy "Dehát ott működött."

 

Felhasználói szemszögből: A readme.txt és a Readme.txt simán lehet hogy két külön fájl. Minden felhasználó járhatott már úgy, hogy case sensitive fájlrendszerből másolt case insensitive-be, és valami kavar volt. Valószínűleg a Könyvelés.xls és a könyvelés.xls szempontjából probléma lehet a könyvelő néninek (ha elkavarja a dolgokat, meg neki egyébként is probléma a számítógép), de hogy lesz neki két külön fájlja alapból: Könyvelés.xls és könyvelés.xls? Nem eleve valami kavarás okozna csak ilyet, vagy az, hogy könyvelő néni trehány?

Egyébként locale, collátor problémái lehetnek?

á == Á, é == É? a == Á? Hogy is van ez?

Mi van, ha pl letölt/átmásol/archivál/visszatölt valamit, ami case insensitive: valami.doc, és Valami.doc. Az egyik fájl elveszik? Case sensitive fájlrendszer esetén nem.

Szerintem a felhasználó szempontjából komolyabb hibák is lehetnek ebből: Nem a case sensitive fájlrendszer esetén fog eltűnni valami fontos (pl szerződés) archiváláskor/visszatöltéskor, hanem a case insensitive fájrendszer esetén.

A case-insensitive kezelés lehet, hogy elsőre felhasználóbarátnak tűnik, de valójában technikailag sokkal bonyolultabb, és sokkal több korlátot is jelent, mint a case-sensitive kezelés.  A fájlrendszernek értelmeznie kell, hogy két név ugyanaz-e (neked triviális hogy két karakter ugyanaz-e magyarul, de annyira nem triviális a probléma ha általánosan akarod kezelni),  bonyolultabbá, lassabbá teszi az egészet, és hibásan is működhet. Cserébe megkötéseket is hoz: nem lehet két azonos nevű, csak case-ben eltérő fájl. Ezzel szemben a case-sensitive fájlrendszer egyszerűbb, következetesebb, és a felhasználónak meg kell tanulnia, hogy a számítógép pontos karaktereket különböztet meg – ami amúgy is alapvető készség, és (szerintem) plusz pont, hogy tudatos felhasználókat igényel. Ennél több dolgot is meg kell jegyeznie valakinek, akit szívesen odaengedek egy számítógéphez.

Ezen felül a case insensitive fájlrendszer lehet, hogy inkább csak régi örökség korai rendszerekből, nem? (amin már nehéz változtatni, mert túl nagy lenne a kompatibilitási törés)

- szerintem.

Szerintem te itt multiplatform inkompatibilitásra hoztál példát, ahol az egyik rendszer sensitive, a másik meg insensitive.

De ez nem use case a sensitive értelmére. Ez egy probléma, ami a kétféle rendszer együttműködésekor (szarul beállitott rendszer esetén) előjöhet.

"egy kódba beleírja valaki azt, hogy require('Config.js'), akkor a fájlrendszerben ne config.js legyen már, mert ez kb olyan érzés, mintha a változók is case insensitive-ek lehetnének."

Nem tudom linuxon hogy működik, ha insensitive-re állitod, de windows-on, ha létrehozol egy Config.js file-t, az bizony Config.js fileként fog látszani mindenhol. Nem veszik el kis-nagybetű információ, ott van letárolva a filerendszeren. DE ezen file később elérhető config.js -ként is és NEM lehet mellé lerakni egy confIg.js-t.

Szerintem te itt multiplatform inkompatibilitásra hoztál példát, ahol az egyik rendszer sensitive, a másik meg insensitive.

De ez nem use case a sensitive értelmére. Ez egy probléma, ami a kétféle rendszer együttműködésekor (szarul beállitott rendszer esetén) előjöhet.

Nem egy homogén világban élünk IT területeken sem. Ezek valós problémák, és use case-ek, amiket case sensitive fájlrendszer alapból kezel. Egy rendszernek más rendszerekkel kell integrálódnia. 

Nem mindenki érzi problémának, hogy az "a" és az "A" az két különböző karakter. A case sensitive fájlrendszer természetes módon, plusz logika nélkül kezeli az eseteket, ha egy másik case sensitive rendszerrel kell integrálódnia (mivel nincs benne korlátozás karakterek tekintetében), míg a case insensitive fájlrendszerben az általam írt problémák jönnek elő.

Ha ma Te terveznél egy fájlrendszert, senki nem kötelezne rá, hogy MS-DOS kompatibilis legyen. Ki mondaná meg, talán Bill Gates? :) Szóval nem biztos, hogy az egész univerzumnak az MS-DOS-hoz, és a CP/M-hez kellene igazodni. Mert vannak rendszerek, amiben nem mertek váltani, mert a saját korlátozásuk kompatibilitási töréseket okozott volna.

A case sensitive fájlrendszer egy természetes választás, amivel ezek a problémák elő sem jönnek, és egy: https://en.wikipedia.org/wiki/KISS_principle megoldás. Azon felül én nem értek egyet az eredeti felvetéssel, hogy a usereknek ez gondot okoz. Akkor töröljük a _ (underscore) karaktert, mert keverik a kötőjellel, sőt, legyenek csak nagybetűk (ha nagyon el akarom túlozni. :)).

Szerintem ez: "2024 Bérszámfejtés.xlsx" és "2024_Bérszámfejtés.xlsx", "2024_bérszámfejtés.xlsx", és "2024-berszamfejtes.xlsx" ugyanúgy gondot okozna. Hol a határ? És ha bárki korlátoz, az magát szúrja tökön, ha egy másik rendszerrel kell integrálódni.

A másik kérdés: Akkor ne csak a fájlrendszereket vizsgáljuk meg az informatikában, milyen olyan területek vannak, ahol ez gondot okozhat még a könyvelő néninek? Adatbázis index?  - Még egyszer: "Szerintem" - Nem kell egyet érteni, csak én így látom. :)

Ráadásul ez technikailag nem is triviális a kérdés: Ránézésre egyszerűnek tűnik kijelentés, hogy legyen case insensitive, de sokkal több karakter van, ami kérdés lehet. Pl egy keleti nyelv karakterei. + az integrációs gondok. 

És mindezt azért, hogy a könyvelő néninek – aki nem ért a számítógéphez – ne kelljen megjegyeznie, hogyan is vannak elnevezve a fájlok? (és a case insensitive kezelés ebben amúgy is csak félig lehet segítség neki)

 

         "egy kódba beleírja valaki azt, hogy require('Config.js'), akkor a fájlrendszerben ne config.js legyen már, mert ez kb olyan érzés, mintha a változók is case insensitive-ek lehetnének."

Nem tudom linuxon hogy működik, ha insensitive-re állítod, de windows-on, ha létrehozol egy Config.js file-t, az bizony Config.js fileként fog látszani mindenhol. Nem veszik el kis-nagybetű információ, ott van letárolva a filerendszeren. DE ezen file később elérhető config.js -ként is és NEM lehet mellé lerakni egy confIg.js-t.

Hát, ez programozóként: Nem számít, hogy minek látszik, hanem az a lényeg, hogy a fájlrendszerben és a kódban mi van. Mi történik, ha valaki config.js-t vesz fel, és Config.js-t ír a kódba. Vagy fordítva. -> A kódban az legyen, ami a fájlrendszerben. Semmivel nem fontosabb, hogy rendben legyen beírva/megtalálva/kezelve egy fájl, mint bármelyik másik case-sensitive elnevezés a forráskódban.

A user szemponjából nincs értelme megkülönböztetni a kis és nagybetűs számot. Ellenben, nagyon is van értelme letárolni azt ahogy irta, mert ha neki úgy tetszik, hogy nagybetűvel kezdődik, akkor úgy is látszon. Ez megoldott CI filerendszer esetén, legalábbis windows alatt.

Ahogy egyébként a CS működés is megoldott alatta, de szerintem kimutathatlan, hogy hány user kapcsolja be, mert igénye van rá.

A biztonsági megfontolásról, nekem egyetlen eset sem jut eszembe, amikor abból lett security probléma, hogy CI a rendszer. Windows-on.

ÉS még egy dolog, tényleg, amit Linus írt:

akkor más véletlenszerű – és esetleg biztonság-érzékeny – fájlok is ugyanolyannak számítanak

Te át tudod gondolni, hogy mit okozhat biztonsági szempontból, ha valaki "okosan" akar plusz logikákat beépíteni a fájlnevek kezelésébe? Én biztosan nem. - csak az egyszerű a legjobb...

Az általam ismert könyvelő droid nem érti a különbséget ugyanabban a könyvtárban tárolt Bérszámfejtés.xls és a bérszámfejtés.xls file között.

És nem is szeretnék nekikezdeni megmagyarázni, hogy miért is volna jó neki, ha meg volna engedve, hogy két ilyen nevű, eltérő tartalmő file legyen ott, mert én is hamar elfogynék az észérvekből...

Van ertelme case insensitive-segnek, csak nem FS szinten, hanem shell/filebrowser szinten. Ha egy open dialogba beirom hogy file.txt, de kozbe a folderbe csak File.txt van, akkor javitsa ki automatikusan (ha ambigous, mert van mondjuk File.txt meg FILE.txt is akkor meg dobjon errort). Save-nel ugyan igy, ha file.txt-be akarok menteni es kozben van egy File.txt, akkor kerdezze meg hogy felul akarom-e irni (meg mondjuk legyen valami jol eldugott opcio hogy en megis file.txt neven akarok menteni). Grafikus programoknal a widget toolkit megoldja, cli-nel a shell, es egyebkent meg open, fopen meg tarsai mukodnek tovabb ugy ahogy vannak most, anelkul hogy a programozonak azon kene fajjon a feje hogy az adott filesystem az hanyas verzioju unicode szabvany alapjan casefoldol, vagy hogy az applenek nem sikerult NFD-t implementalnia rendesen.

I hate myself, because I'm not open-source.

A case sensitive megoldás mellett szóló érvek:
1) egyszerűbb, minden csak bitkép alapján dől el, nyers bájtok szerint. Nincs manipulálgatás, fetrengés, hogy mi minek felel meg, minek a upper/lower case megfelelője, nincs bonyolítás a kódolás szerint, stb.. Egyszerűen csak el van tárolva a fájl, mappa, link, stb. neve, és csak teljes egyezés esetén utalnak ugyanarra a fájlra, mappára, stb.. Egyszerűség, sokkal kevesebb programsorból implementálható, ami kevesebb lehetséges bugot, sechole-t hoz magával.
2) rugalmasság, nem korlátozza le a felhasználót, ha már van az adott mappában egy hasonló fájl, hogy ne használhasson ahhoz nagyon hasonló nevet, ami csak kis/nagybetűben tér el.
3) biztonság, rossz indulatú fél, kód nem tud odapreparálni a fájlrendszerre egy hasonló fájlt, pl. Bináris helyett bináris néven, amit a felhasználó véletlen a bináris helyett tudna futtatni.

Tradicionálisan a Unix sose fogta a felhasználó kezét, nem voltak benne hülyebiztosított, egy klikkes megoldások, meg bekészített védelmi mechanizmusok. Emiatt nem megbocsátó, pl. CLI-ben valamit rosszul paraméterezel, simán végig dd-zheted a telepítésed, szétrongálhatod a fájlrendszert rm, chmod, chown, stb. mentén, ha rosszul adod ki rekurzívan, pipe-okkal simán felülírhatsz fontos fájlokat, stb.. Sose volt egy hülyéknek szánt rendszer, nem próbálta megvédeni a felhasználót önmagától.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Amugy most igy megegyszer vegiggondolva az egeszet, ennyi erovel a konyveles2024.xls-el mi ujsag? Az miert kene mas fajl legyen mint a könyveles2024.xls? Vagy konyveles_2024.xls vagy 2024nyilvantartas.xls vagy ...

Az a baj hogy az emberek agya az nem egy bytesorozatot tarol, a szamitogep pedig de es kene talalni valami kompromisszumot ami a userek szamara se nagyon idegesito, es cserebe nem nagyon bonyolult implementalni. A case insensitive FS egy ilyen dolog, amig a foldgolyo csak az USA-bol all, onnantol kezdve hogy nem csak ASCII karakterekre kell mukodnie, gyorsan elkurvulnak a dolgok. Persze az is jo kerdes hogy miert ragaszkodunk egyaltalan a filenevekhez, es miert nem valami semantic cucc van helyette, es akkor a case sensitivitas mehetne abba a kupacba hogy a TCP miert random megjegyezhetetlen szamokat hasznal portoknak mint pl 22, 80, 443, miert nem human readable stringeket mint pl SSH, HTTP, ...

I hate myself, because I'm not open-source.

Én el tudom képzelni, hogy a kibővített latinbetűs (főleg az európai országokra gondolok, néhány kivétellel mint pl. Törökország, és Európa határa [keletről] a Románia-Bulgária tengely (jó ez vicc volt) {hú, ez egyre bonyolultabb}) abc esetén jól működhet a kis- és nagybetű érzéketlenség. Csak párszáz, esetleg egy-két ezer kilométer megtétele után olyan latinbetűs országok jönnek mint Törökország, vagy Azerbajdzsán hogy mást ne írjak.

Ott fog eldőlni a betűérzéketlen fájlrendszer Jenga tornya. (Ez csak vélemény, nem igazság)

Egyébként a nyitóban leírt Linus-féle érvelés rossz, mert a fekete szív és a piros szív akár kicsi akár nagy, mindenképpen különbözik egymástól.
Meg kellene már tisztességesen tanulni a bridge-t, és akkor nem jönnek hülye példákkal.

Még nincs aláírásom.

Nem kell, ha valakinek az az igénye, hogy egy file-t különböző neveken el tudjon érni, megteheti, mint már írtam is.

De visszakérdezek: miért akarna valaki egy file-t két (vagy több) különböző néven elérni? Mire lenne az jó?

A választ erre is az fogja megadni, akinél ez az igény fölmerül. Neked nem kell rajta töprengened.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Azért meg nagyon bonyolult olyan algoritmust állítani, ami kivédi ezt. Mert jelen példában mi emberek látjuk, hogy csak félreírás, de algoritmust erre nehezen állítasz, hogy próbálod kitalálni, hogy mire gondolt a költő/felhasználó. Ne, ne találgassunk, az a legrosszabb, mert elkezdünk hülyeséget feltételezgetni. Ha ilyen védelmet akarsz, azt a userspace alkalmazásban érdemes implementálni, hogy ilyen fájl mentése előtt végignézi a mappát, és ha talál nagyon hasonló fájlt, akkor rákérdez. Az még okés egy GUI-s programnál. De egy CLI/TUI programnál ne találgasson végképp, ott agyhalál is lenne, hogy a szkriptben meg az általad paraméterként megadott, pipe-ban átadott adatokat elkezdené találgatás alapján felülbírálgatni.

Pont ez a mai modern operációs rendszerek rákfenéje, hogy mindent próbálnak a felhasználó helyett kitalálni, jobban tudva nála is, hogy mit is akarhat, meghoznak a háta mögött döntéseket, önállósítja a rendszer magát, meg előírja, hogy te mit hogy használhatsz, nem telepíthetsz gyanúsnak tűnő programot, rádkényszeríti a telemetriát, frissítéseket, online fiókot, titkosítást, stb.. Ez egy olyan tré megoldás, ami csak lejjebb visz a szarörvénybe, és csak a gond van vele.

Egyébként meg a példádnál maradva ilyennek elő sem kéne fordulnia helyes felhasználásnál. Mert mikor menti a Könyvelést2024.xls-t, akkor hogy nem látja, hogy már van egy könyvelés2024.xls? Mert ha az utóbbit akarta szerkeszteni, akkor nem új dokumentumként kellett volna megnyitni, és később menteni, hanem eleve a könyvelés2024.xls-t kellett volna megnyitnia és azt szerkesztenie, majd végül mentenie azonos néven. Ilyet csak sík idióták csinálnak, hogy már van egy olyan fájl, de erre elment helyette hasonlót.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Hús-vér userek a "milyen operációs rendszer fut a gépeden" kérdésre azt válaszolják, hogy "ööö... nem tudom... Facebook?", szóval nekik tök mindegy, nem csak a fájltartalom-típusjelölést, a fájlnév többi részét is fölösleges megmutatni nekik, elég lenne egy "emodzsi" (gyűlölöm ezt a divatszót).

Igen, ezt én is utálom. Főleg, hogy mindent ennek a rétegnek az érdekében hülyítenek el. Elrejtik előlük a kiterjesztéseket, rejtett fájlokat, a modern fájlkezelőkben már a mappa-fájl paradigma is megszűnt, helyette egy szintre vannak behányva meg kategorizálva a „dokumentumok” típusai, és ahogy a gnome-osoknál, már a fájlkezelőnek sincs neve, csak Files, vagy Fájlok. A menük is meg lettek szüntetve, egy áttekinthetetlen ribbon vagy hamburgermenü van helyette, az összes ilyen alkalmazás használhatatlanra van butítva, hogy nem tudod vele átnézni, hogy mi hol van a rendszeren. Az ilyen borzalmakban a keresési, átnevezési funkció is egy primitív megoldás szokott lenni. Kösz, de nem.

Nekem az első dolgom, hogy minden általam használt rendszeren legyen valami normális kétpaneles commander-klón, amivel látom is, hogy mit csinálok, milyen mappa, fájl, hol van, milyen mélységben, látszódjanak a kiterjesztések (ez nekem akkor is fontos, ha unixlike rendszeren ezek nem léteznek, nem szólnak bele a fájlok kezelésébe, mert mime/fejléc, tartalom, shebang, jogosultság alapján dől el, hogy melyik alkalmazásban nyílnak, futnak dolgok), rejtett fájlok és mappák, meg legyen különböztetve, ha valami link, fifo, vagy egyéb, futtatható vagy nem futtatható, stb.. Lássam egy műveletnél egyszerre a forrás és célmappát, fájlméreteket, mennyi hely van az adott fájlrendszeren, csatolási ponton, stb.. Ezek olyan alapok, amik nélkül nem lehet normálisan fájlokat kezelni, mert az ember nem látja, amit csinál.

Néha használok fuzzy find megoldásokat, dmenu, fzf, stb., azok valóban összemossák, hogy melyik fájl hol van, milyen mélységben, meg nagyon távoli egyezések alapján is megtalálnak dolgokat, de azokat csak gyors megnyitáshoz használom.

Linuxban is külön utálom, hogy a grafikus programokban készre van drótozva a Gtk vagy Qt filepicker, amik jó nagy fosok szoktak lenni, és nem lehet őket átdrótozni saját magoldásra. Pedig marha egyszerű lenne, mert miután egy filepicker-ben választottál, fájlt, fájlokat, mappát, mappákat, csak pár karakterláncot ad át (/eleresi/ut/fajlnev1 /eleresi/ut/fajlnev2 stb.) a hívó programnak, ehelyett nyugodtan használhatnék fzf-alapú saját szkriptet, de a Qt-sek, meg Gtk-sok eldöntötték, hogy azt nem lehet. Nem illik, mert az ő freedesktop paradigmájukba nem fér bele.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Elrejtik előlük a kiterjesztéseket

Eleve a kiterjesztés mint olyan, egy baromság, mint a fájlnév része.

Az, hogy egy adott fájl milyen típusú, az egy olyan metaadat, aminek felesleges a fájl neve részének lennie. És lehetne ez egy MIME típus leíró, metaadatként. Semmi keresnivalója a fájl nevében. Ahogy ezt a Unix anno jól ki is találta - nem létezik olyan dolog, hogy fájlkiterjesztés.

Linuxban is külön utálom, hogy a grafikus programokban készre van drótozva a Gtk vagy Qt filepicker, amik jó nagy fosok szoktak lenni, és nem lehet őket átdrótozni saját magoldásra.

Ha egy alkalmazás jól van megírva, akkor használja az XDG FileChooser portalt, és te eldönheted, milyen FileChooser implementációt kínálsz az alkalmazásnak. Ponthogy a freedesktop találta ki ezt a paradigmát, és pont azért, hogy ne legyen a user konkrét implementációhoz kötve.

Igen, kicsit windows-os beidegződés, meg redundáns, de van haszna. Pl. szelektíven tudok fájlokat megnyitni, GUI programokban mime-típus alapján, terminálosakban akár fájlkezelőnként külön differenciálom, pl. másban nyit meg egy adott fájltípust a vifm, másban a sfm vagy lf, megint másban nyitja meg az mc. Arra jó lehetőség.

Azért is írom, hogy kiterjesztés nem létezik *nix rendszerekben, .akármi csak a fájlnév része, de modern alkalmazások tudnak ennek a mentén különbözően megnyitni.

xdg/mime-választó szkritpem máris van, ami egy fzf-fel kikeresett fájl típusához enged választani társított alkalmazást xdg-mime default parancsot meghívva, de ez csak GUI alkalmazásokhoz szükséges rossz, a freedesktop kompatibilitás miatt, de ne felejtsd el, hogy én 99%-ban nem használok GUI-t, hanem TUI és CLI megy helyette, vifm/fzf/neoviim workflow-val. Ez az XDG/freedekstop mime meg .desktop fájlok, portálok, stb. GUI-s alkalmazásokhoz lettek kitalálva.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

használja az XDG FileChooser portalt, és te eldönheted, milyen FileChooser implementációt kínálsz az alkalmazásnak

Baszhatom ha a gtk2 ota senkinek se sikerult olyan file choosert irnia ami legalabb tavolrol emlekeztet egy hasznalhato valamire. Ami qt-ben van az a windows-os 1:1 koppintasa, a gtk3 filepickere meg annyira szar, hogy ha csak feldobna egy textboxot barmifele completion nelkul, meg az is erolelepes lenne hozza kepest.

I hate myself, because I'm not open-source.

( kassaiviktor | 2025. 04. 27., v – 12:47 )

macen is azért nem lehet case-sensitive-re állítani a fájltendszert, mert az egyetlen program, ami miatt nem linuxot használok daily drivernek, a photoshop elhasal azon, az adobe hibájából!

amúgy egyszer érdekelne, hogy hogyan kezeli az ilyen isensivity pl a török i betűket (ı, I vs i, İ)

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

De, kezeli, a LOCALE-nek megfelelően, az ahhoz tartozó COLLATION-t használva, ha törökre van ez állítva, akkor ki tudja silabizálni, hogy melyik betűhöz melyik nagy és kicsi variáns tartozik. De épp erre utalt Torvlads, az ilyen kétélű fegyver, mert ahogy egy ilyen fájlrendszer felcsatolsz egy másik gépen, ahol másik LOCALE van érvényben, máris megy le a lefolyóba az egész, ami korábban egy fájlnak, mappának számított, az most kettő lesz.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Hat, Linuxon biztos hogy nem, ugyanis a linux kernelnek fogalma sincs arrol mi az a locale, az egy teljesen userspace dolog.

Amugy meg fs-nek nem kell a full collation support, annak csak case folding kell, ami tobbe kevesbe nyelvfuggetlen, a torok i betuket leszamitva. Pl. ICU-ban a case foldingnak lenyegileg egyetlen optionje van, hogy a torok i betuket akarod vagy a rendeset: https://unicode-org.github.io/icu/userguide/transforms/casemappings.html Hogy ne legyen ebbol a teljes katyvasz amit felul irtal, tudtommal a case sensitive OS-ek ezt siman falsenak veszik, a torok userek meg igy jartak. (De igazabol tokmindegy, fizikailag nem lehet jol megcsinalni)

I hate myself, because I'm not open-source.

Esetleg, ha ennyire fontosnak látszik, hogy milyen betűket-karaktereket használ a fájlrendszer mint a fájlnév alkotói, rá fog valaha is döbbeni egy FS fejlesztő, hogy azzal foglalkozni kellene?

Tudom költői kérdés volt. Amúgy a különféle UTF-ek simán kódolhatták volna a kis- és nagybetű párosságot kifejező adatokat. Csak éppen nem tették. Vagy ha tették, akkor sokan nem tudnak arról, hogy olyan létezik. Mit görcsöltem én annak idején ilyenekkel. Pedig csak el kellett volna olvasni a táblázatban az arra mutató megjegyzést.

Ja, és az az "i" betű nem csak a török nyelvben létezik. De még mennyire "nem csak". Jobb ha tudod.

Még nincs aláírásom.

milyen betűket-karaktereket használ a fájlrendszer mint a fájlnév alkotói, rá fog valaha is döbbeni egy FS fejlesztő, hogy azzal foglalkozni kellene?

A baj ezzel, hogy ez alapvetoen nem egy filerendszer kerdes, hanem OS kerdes, es amikor ezeket az OS-eket eredetileg kifejlesztettek, akkor volt az ASCII (esetleg valami kezdetleges support nehany nyugat-europai nyelvhez), ott meg trivialis ez a kerdes. Csak aztan jott a felismeres hogy esetleg amerikan kivul is leteznek emberek, jott a unicode, aztan borult az egesz egyszeruseg.

simán kódolhatták volna a kis- és nagybetű párosságot kifejező adatokat

Egyreszt nem ilyen egyszeru (pl. a nemet ß nagybetusitve SS, azaz ket karakter), masreszt meg erre ott vannak a kulonfele ucd tablak (https://www.unicode.org/Public/UCD/latest/ucd/) amibe benne van mindez (meg egy csomo mas). Meg csak az kellene hogy az amugy is 21 bitnyi unicode karakterkodok melle meg el kene tarolni 100 bitnyi flaget, teljesen redundansan minden karakter melle.

I hate myself, because I'm not open-source.

A kernelnek nem, de a kernel módban futó rendszer az a rendszeren beállított LOCALE, LC, LC_* környezeti változókból szedve. Ezek minden rendszeren léteznek, legfeljebb azért nem tudsz róla, mert a grafikus telepítő beállítja ezt a GUI telepítőből telepítésnél, de minimalista disztróknál (Gentoo, Arch, Void, stb.) neked kell beállítani. Sőt, ez a lokalizációs beállítás akár felhasználónként vagy egy felhasználón belül futtatott programonként is változat. Pl. ugyanazon a gépen, ha user1 jelentkezik be, akkor neki a magyar (hu_HU.UTF-8), míg ha user2, akkor annak meg a török (tr_TR.UTF-8), de még ezen a user2 csavarhat, ha pl. terminálban vagy szkriptből mondjuk a Midnight Commandert meg LC_ALL=C mc vagy LOCALE=en_US.UTF8 mc kiadásával futtatja. Már ki van húzva egy ilyen rendszer alól a szőnyeg, pedig gépet sem, esetleg usert sem váltottunk. A FILE magyarul és US angolul kisbetűsen file lesz, de a török lokalizációnál fıle (pont nélküli kis i). Észre sem veszed, de már benne vagyunk a szarörvényben, pedig még el sem jutottunk a hangkörnyezetfüggő arab karakterekig, meg dupla szélességű ázsiai (pl. japán, kínai) karakterekig, amikkel még hatványozottan több szopás lesz. Torvalds pont arról beszél, hogy ilyenbe nem menjünk bele, mert csak feleslegesen ül fel mindenki vele a szopórollerre. Megnyitják vele az utat egy soha véget nem érő rémálomnak, meg egy csomó új bugnak.

Anno az ilyen szarkeverést engedték URL-ekben, van is vele rendszeresen visszaélés, hogy két azonosnak vagy nagyon hasonlónak kinéző Unicode karakter mentén tévesztenek meg URL-ekkel csalók egyszeri felhasználókat. Ott sem volt túl jó ötlet.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Az UTF-8 az csak egy enkódolás, egy szabályrendszer, hogy Unicode code pointokat hogyan kell reprezentálni bytesorozatként.

Az UTF-8 semmit nem tud arról, hogy egy code point kisbetű-e, nagybetű-e, mi az, hogy locale stb.

A locale meg collation információ az nem UTF-8-tól függő dolog, azt a Unicode adott verzióiban lévő CLDR (Common Locale Data Repository) írja le, és a glibc implementálja: https://sourceware.org/glibc/wiki/Locales

Semmi, de semmi köze az UTF-8-nak ehhez.

Akinek van kéznél németre konfigurált Windowsa kipróbálhatná, hogy létre tudja-e hozni ezt a két fájlt ugyanabban a könyvtárban: "Straße.txt" és "STRASSE.txt". Ezt mindig is ki akartam próbálni.

https://community.snowflake.com/s/article/why-latin-small-sharp-s-upper…

Thus, with the default Unicode casing operations, capital sharp s will lowercase to small sharp s, but not the reverse: small sharp s uppercases to "SS".

( Sulc v | 2025. 04. 27., v – 14:01 )

"Linus ideges, mert 40 év alatt sem sikerült senkinek rendesen megírnia a toLower() függvényt"

dehát ezt írtam föntebb. neked és nekem, és világ legnagyobb részének a `toLower('I')` eredménye az `i`. de a törököknél az bizony `ı`. mert a `toUpper('i')` náluk `İ`. és ez csak locale beállításnál van így

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.