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...

De a táblázat csak rengeteg helyet foglal, nem oldja meg a problémát, ahogy az exFAT esetében sem.
(Egyébként is, ki az a hülye, aki a komlpett konverziós táblát tárol a pár karakteres locale kód helyett? A konverziós tábla úgysem változik, az lokálonként mindig ugyanaz marad, tök felesleges tehát erre pazarolni a drága tárhelyet minden egyes köteten. Arra mondjuk jó, hogy elromoljon aztán meg nézzen bambán a felhasználó, hogy miért lesz a kis "b"-ből nagy "A"...)

( 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).

Nézed meg az javanéz írást. Nem minden betűnek van nagybetűs alakja, és ott sem mindegy az, hogy a betű milyen pozícióban van. A javanéz írás 20 betűjéből csak 9-nek van murda megfelelője, de ezeket is csak akkor használják, amikor tulajdonneveket írnak. De ha egy névben az első betűnek nincs murda megfelelője, a névben az első alkalmas betűt kell murdával helyettesíteni.

( 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.

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.

Hát dehogynem, pont azok, amiket írtam (a user is ezen a világon él, nem csak az Ő rendszere, és fájljai léteznek.). Szerintem meg nem okoz neki nagy terhet ezt kezelni, cserébe egy csomó cross platform kérdéstől szabadul meg. Ha ez valós kérdés lenne neki, akkor szerintem hülyeségre nincs orvosság, mert kb két perc megérteni, és megjegyezni, hogy a kis és nagybetű eltérő értékek. :) A többieket ne korlátozzuk már. :) Én ezt tipikusan (CI fájlrendszert) egy "user feature"-nek hazudott, történeti/kompatibilitási okból létező korlátozásnak gondolom.

 

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 rendben van, case sensitive módon is pont így látszódik. Sőt, ahogy írta, az úgy van ott. Ha kis neveket szeretne adni, akkor adhat azt is (ha fél, hogy nem tudja megkülönböztetni később).

 

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.

Nem tudunk róla. (és nem is tudhatunk, elég hosszú története van, rengeteg security issue, sérülékenység került már elő)

És még egy: nem csak a windows létezik, és más case insensitive fájlrendszer is lehet. Akkor azt ott egyedileg át kell gondolni mindig, és gondolom Linus futott már bele furcsa megoldásokba az egyedi logikákban. (egyébként nem írta volna)

A biztonság pedig egy speciális terület/kérdés, mert abból soha nem lehet elég. Ha bármit ki tud védeni az, hogy nincs egyedi logika, túlbonyolítás - akár kis nagybetűsítés - de legyen bármilyen speciális karakter kezelés/átugrás, akkor az egy plusz. Ha véletlenül van egy programhiba, akkor ezeken a plusz biztonságokon szokott múlni, hogy van-e belőle komolyabb gond, vagy végül nincs. (amiket előre nem is lehet tudni). - Nehéz, mert ezeket nem lehet jól átgondolni előre, csak tapasztalat alapján kerülni tudod a problémákat. Linusnak pl lehet ilyen érzéke a 35 év tapasztalatával, érdemes lehet hallgatni rá.

É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?

Igen.

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.

Gondot is okoz. Nem véletlenül van egy csomó dokumentumkezelő rendszer, amiben ilyenkor feljön a warning, hogy hahó, tuti ezt akartad-e.

É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 egyik user becommitolja a jozsi.cpp-t, a másik a Jozsi.cpp-t, mindkettő felmegy.

Ez világos, de az én kérdésem pont az, hogy erre mi a valós use case. Miért commitolná be? Van egy coding standard jó esetben a cégnélm az megmondja, mi legyen a fájlnév.

Illetve miért commitolhatja be? Desktopon még mindig kétharmad feletti a Windows részesedése, ezt code review-ban meg kéne már fogni, hogy hello, balhé lesz ha merge-ölik a PR-t. 

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

És nem lehetne, hogy a fejlesztők igazodnak kivételesen a userekhez, és nem fordítva? :)

Fejlesztőként is az a biztosabb megoldás, ha case-insensitive-nek tekinted a fájlrendszert, és nem hozol létre ugyanolyan jelentéstartalmú fájlneveket, különböző case-szel. 

Cserébe megkötéseket is hoz: nem lehet két azonos nevű, csak case-ben eltérő fájl. 

Szerintem ez egy nagyon jó mnegkötés, egyelőre továbbra sem látom, hogy a könyvelés2024.xls és a Könyvelés2024.xls szemantikailag miért különböző adathalmaz.

adig jááár a körsó a kutra Míg el nem töri a goja. tssáél ala,azkodnmi.

A legtöbb dolog azárt válik rosszá, mert a leggyengébb láncszemhez akarják igazítani, hogy a hülyék is könnyen tudják használni. De a hülyék kreatívak és mindig találnak ki még nagyobb baromságot. 

Nem értünk egyet, sok usecase-t és valós kérdést írtam.

Szerintem ez nem egy valós probléma a usernek. Nincs szó arról, hogy a fejlesztőhöz igazodjunk, és a Marika néni és egy fejlesztő között még 1000 fokozat van. 

Plusz ha mindenben könyvelő nénihez igazodnánk (a NASA is), hogy neki ne kelljen 1 perc alatt átgondolni, hogy mit csinál, akkor nagyon sok lehetőségtől esnénk el.

Egy kódtár meg lehet hogy 15 év eredménye, minden előfordulhat ez idő alatt.

code review-ban meg kéne már fogni, hogy hello, balhé lesz ha merge-ölik a PR-t

Igen, oda kell figyelni a fájlnévre, meg még 1000 dologra. Ha elcseszik, case sensitive fájlrendszerrel el sem jutnak idáig. -> kezeli a kérdést automatikusan

Fejlesztőként is az a biztosabb megoldás, ha case-insensitive-nek tekinted a fájlrendszert

Azt Te sem várhatod, hogy csak a case insensitive fájlrendszereket tekintsük valid fájlrendszernek egységesen - addig meg okoz cross platform kérdéseket.

+ Szerintem az egyszerűbb, megkötések nélküli a jobb. (jobban igazodik mindenhez körülötte)

Plusz ha mindenben könyvelő nénihez igazodnánk (a NASA is)

A NASA-nál mi a use case arra, hogy a mars_felvétel.avi és a Mars_felvétel.avi különböző adathalmazt jelöljön? :)

Ha elcseszik, case sensitive fájlrendszerrel el sem jutnak idáig. -> kezeli a kérdést automatikusan

Hogy kezeli? Van egy valami.py és egy Valami.py fájlod, melyik lesz az "igazi" verzió? Vagy két teljesen különböző tartalmú fájlról van szó? Akkor miért ~ugyanaz a nevük?

Azt Te sem várhatod, hogy csak a case insensitive fájlrendszereket tekintsük valid fájlrendszernek egységesen

Tekintve, hogy a desktop rendszerek kétharmadánál is több fut case-insensitive fájlrendszeren, szerintem nyugodtan tekinthetjük defaultnak.

A NASA-nál pl egy interfészen pl fájlokat kapnak egy külső helyről (nem a Mars_felvétel.avi-t a marketing osztályon, hanem mást), és case sensitive formában tárolják a fájlneveket, ami mondjuk fel is van sorolva egy xml-ben, vagy db-ben, vagy bárhol. Szerinted térjen át mindenki Marika néni kedvéért. -

De szerintem alapból egy valid választás az egyszerűbb, és több lehetőséget biztosító megoldás (a case sensitive, ami kevesebb logikát és hibalehetőséget tartalmaz) egy olyan helyre, ahol a stabilitás a kérdés, és minden felesleges problémát el akarnak kerülni. És egy bármilyen enterprise usernek nem ugyanaz számít egyszerűbbnek, mint a könyvelő néninek.

A case insensitive kezelés, amúgy szerintem nagyon sok kérdést felvet, nem olyan egyszerű, mint itt neked elsőre tűnik, magyar nyelven.

de valójában technikailag sokkal bonyolultabb

User: not my problem.

nem lehet két azonos nevű, csak case-ben eltérő fájl.

Mi rá a valós életbeli use case? Mindig mondják a case sensitive fájlrendszer mellett pártolók, de olyat még nem láttam, hogy bárki, szándékoltan erre akart volna funkciót építeni vagy ilyet akart volna csinálni.

User: not my problem.

Nos, ha Gizikéne arra van igénye, hogy picimuci nyuszokák jelenjenek meg a szabványos megoldás helyett, akkor fizethet valkinek azért, hogy megcsinálja számára a piszimucinyuszikák wrappert. 
Ha van egy hatékony, jól működő, szabányos rendszer, akkor a hülyék számára beteendő réteget fizessék meg a hülyék.

Ha meg nyuszimuci nem érti, hogy ez egy extra igény, akkor annyiban is maradhat a dolog, hogy "így kell csinálni és kész", ha nem tetszik, akkor elmehet kapálni. De ha nem tudja a különbséget a dudva és a palánta közt, akkor kapáltak neki. Az inkompetenciát nem plusz befektetéssel, a feladat megoldásának primitív lépéseit túlbonyolítva más nyakába varrásával lehet orvosolni, hanem mucika kirúgásával.

Otthon, szabadidejében, akármikor persze lehet butus, de ott is neki kell megfizetnie azt, hogy valaki fogja a kezét és helyette gondolkodó gépet csináljon neki. Ha nem, akkor max a természetes szelekció megoldja.

Ha Linus gépek számára akar fájlrendszert csinálni, akkor ott eleve nem merül fel nem hogy kisbetű és nagybetű probléma, hanem betűprobléma sem. Szóval amíg végső soron emberek fizetik az ő munkáját, és nem kimondottan gépeknek akar fájlrendszert csinálni, addig lesz szíves kiszolgálni az emberi igényeket. Esetleg fel kéne fogni, hogy pl. az emberi kézbe való véső és a különféle véső-gépekbe való véső formája különbözik. Ha Linus vagy bármelyik illetékes nem tudja megugorni a feladatot, elmehet pl. öltözködési tanácsadónak.

:)

Ühüm. A program létrejöttéhez és futásához szükséges fájlok elnevezésekor a programozó használjon kizárólag angol kisbetűket, arab számokat, alulvonást és pontot. Ennyi. Nem olyan bonyolult ez, főleg egy olyan korban, amikor egyes szoftveres közösségekben azt is előírják, hogy a csoport részét képező egyén hogyan vélekedjen a világról.

Esetleg fel kellene fogni, hogy az emberek mire és hogyan használják az állományokat. Segítek: a fájlban tárolt (vagy tárolni kívánt) bitek által hordozott tartalom alapján születik meg az ember fejében az a karakterlánc, amit végül fájlnévnek használ. Amíg az ember és a gép közösen olvassák ugyanazt a fájlrendszert, elvárható, hogy ne az embernek kelljen alkalmazkodni.

:)

A program létrejöttéhez és futásához szükséges fájlok elnevezésekor a programozó használjon kizárólag angol kisbetűket, arab számokat, alulvonást és pontot.

Te sem programoztál még soha, legalábbis Java-ban, C#-ban, Swift-ben, Kotlin-ban, és Objective-C-ben biztos nem..

Segítek: https://www.oracle.com/java/technologies/javase/codeconventions-introdu…

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-sty…

https://www.swift.org/documentation/api-design-guidelines/

https://kotlinlang.org/docs/coding-conventions.html

https://google.github.io/styleguide/objcguide.html

Ezek olyan névkonvenciók, amiktől szentségtörés eltérni, beleértve hogy a fájlok elnevezésekor nem csak "kizárólag angol kisbetűket, arab számokat, alulvonást és pontot" használsz.

Megkértem neked a chatgpt-t, hogy keresse ki a releváns részeket (Search funkcióval, Te is megtehetted volna):

Java

"Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words—avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML)."

C#

"By convention, C# programs use PascalCase for type names, namespaces, and all public members."

Swift

"Names of types and protocols are UpperCamelCase. Names of functions and variables are lowerCamelCase."

Kotlin

"If a Kotlin file contains a single class or interface (potentially with related top-level declarations), its name should be the same as the name of the class, with the .kt extension appended. It applies to all types of classes and interfaces."

Objective-C

"File names for categories should include the name of the class being extended, like GTMNSString+Utils.h or NSTextView+GTMAutocomplete.h"

 

Ezt írta még:

 

Java

C#

  • Névkonvenció: Az osztályok nevei PascalCase formátumúak, és a fájl neve megegyezik az osztály nevével.

  • Példa: MyClass.cs fájlban szerepel a public class MyClass.

  • Hivatalos dokumentáció: Common C# code conventions

Swift

  • Névkonvenció: A fájl neve tükrözi a benne található fő típus nevét, PascalCase formátumban.

  • Példa: MyViewController.swift fájlban szerepel a class MyViewController.

  • Hivatalos dokumentáció: API Design Guidelines - Swift.org

Kotlin

  • Névkonvenció: Ha a fájl egyetlen osztályt vagy interfészt tartalmaz, a fájl neve egyezzen meg az osztály nevével, PascalCase formátumban. Több osztály vagy top-level deklaráció esetén a fájl neve tükrözze a tartalmát.

  • Példa: MyService.kt fájlban szerepel a class MyService.

  • Hivatalos dokumentáció: Coding conventions | Kotlin Documentation

Objective-C

  • Névkonvenció: A fájl neve tükrözi az osztály nevét, beleértve a nagybetűket is. A header fájl .h, az implementációs fájl .m kiterjesztésű.

  • Példa: MyViewController.h és MyViewController.m fájlokban szerepel a @interface MyViewController és @implementation MyViewController.

  • Hivatalos dokumentáció: Google Objective-C Style Guide

 

Amíg az ember és a gép közösen olvassák ugyanazt a fájlrendszert, elvárható, hogy ne az embernek kelljen alkalmazkodni.

Például a névkonvencióak is emberek találják ki, és nem feltétlen azt jelenti az, "hogy nem az embereknek kell alkalmazkodni", hogy Marika-nénit vesszük alapul, aki nem tudja a kis és nagy betűt megkülönböztetni a számítógépén.

Átfutottam a HUP-on megjelenő szöveget. A felsorolásban egy laikus számára semmi sem indokolja, hogy ne lehessen kisbetűs a fájlnév. Gondolom, a programozó együtt tud élni azzal, hogy nem használ együtt "FüggVény", "Függvény", "függVény" és "függvény" nevű függvényeket.

:)

De indokolja, és nagyon nem érted ezt.

Aki ilyet csinál, az első pillanatban elveszíti el mindenki bizalmát, mert egy alapvető szakmai normát rúg fel. Ez nem szabad értelmezés kérdése, hanem a világon mindenhol elfogadott névkonvenció.

Ezen felül ez nem csak stílus kérdése, hanem pl a java fordítód le sem fordítja a programot, ha a fájlneved nem egyezik meg az osztálynévvel.

Ékezeteket és egyéb barom karaktereket nem illik amúgy. Szerintem az egyik legnagyobb hülyeség lenne, amivel szívathatná magát és a másikat a programozó.

És közben eszembe jutott, hogy hibát is nyomoztam ilyen miatt (kigenerált jar fájlnak a nevében volt valami, amiből lett valami hiba). (és minden UTF-8, de hányingere lesz az embernek. :)) - Ilyet egy jóérzésű programozó nem csinál.

Például a névkonvencióak is emberek találják ki, és nem feltétlen azt jelenti az, "hogy nem az embereknek kell alkalmazkodni", hogy Marika-nénit vesszük alapul, aki nem tudja a kis és nagy betűt megkülönböztetni a számítógépén.

Irreleváns. A programozónak lehet saját CS fájlrendszere a fejlesztéshez. Nem olyan nagy dolog ez, ha már a fejlesztéshez szükséges szoftvereket úgyis konténerrel telepíti, a tesztelést meg virtualizált környezetben végzi...

:)

Szerintem meg Marika néni irreleváns, legyen neki egy dokumentum kezelő rendszere, valami fájlrendszer felett futó wrapperje, vagy bármi, ha neki meggyűlik a baja a fájlrendszerekkel.

De ne csak a programozókra gondolj. 1000 másik terület lehet, ahol a user CS fájlrendszert szeretne. A usereknek is kérdés, pl a cross platform problémák miatt, amit az eltérő fájlrendszerbeli működésnek előhoznak. (csak nem arra gondolsz, hogy csak CI fájlrendszerek legyenek az univerzumban, hogy ne legyen gond)

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...

Az biztos, hogy szuboptimális. mert ha ugyanabban a könyvtárban van (márpedig szerintem abból indultunk ki (*) ), akkor a hard link az optimális megvalósítás. ;-)

(*) ha nem ugyanabban a könyvtárban van a Könyvelés2024.xls és a könyvelés2024.xls (**), akkor fogja tudni a drága könyvelő néni, hogy mi köztük a különbség? Sajnos nem, ezért szüntessük meg a könyvtárak kezelését is!

(**) esetleg egy harmadik helyen pedig van egy konyveles2024.xlsx és mivel el van rejtve a kiterjesztés és csak felismerhetetlen és megkülönböztethetetlen ikonokkal jelöljük a különbséget (de persze rendelhetünk hozzá 2 külön programot is akár!) ezért még annyira sem tudja megkülönböztetni őket

Végkövetkeztetés: legyen CI fájlrendszer, ami mappákat (pláne nem könyvtárakat!) sem kezel, mint a C-64 floppimeghajtóján.

Vagy mégis csak edukáljuk a felhasználókat. (Mi a bánatnak különböztetjük meg a Rákóczi utca / Rákóczi út / Rákóczi tér közterületeket.)

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

edukáljuk a felhasználókat.

Ha az informatikai szereplők a 2025-ben általánosan rendelkezésre álló számítási kapacitással nem tudnak egy informatikai problémát jól és emberközpontún megoldani, szerintem ne a felhasználókat edukálják, hanem saját maguk iratkozzanak be edukálásra.

:)

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.

Hat majd ha egy mappa megnyitasa errort fog dobni, mert sikerult belerakni ket olyan filet ami egy korabbi unicode verzio szerint meg kulon karakternek szamitott, uj verzio szerint meg nem, akkor fog majd fajni. (Nyilvan gyakorlatban inkabb valahogy kornbeganyoljak, lasd apple ami mai napig valami unicode 3 alapu normalizalast hasznal, hogy ne torjek el a filerendszer kompatibilitast.)

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

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

Olvass följebb, pontosan ezt a megoldást javasoltam, de Imo nem volt vele elégedett. Ezzel a kérdéssel arra akartam utalni, hogy ne zárjon ki lehetőségeket csak azért, mert szerinte senkinek nincs rá igénye. Valakinek biztosan lesz.

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

Hu nekem inkabb ott az workaroundnak tunt a case-insensitive-seg hianyara, arra tenyleg eleg rossz otletnek tunik symlinkeket hasznalni. De az altalanos problemara, hogy egy file tobb neven/utvonalon is elerheto legyen, arra sok esetben egy jo megoldas.

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

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)

Javaslom elolvasni A Pál utcai fiúk c. művet, nyilván hallottál róla. Abban az egyik szereplő annyira komolyan vette a kisnagybetű különbséget, hogy bele is halt.

És szerintem ezt a példát még az ominózus könyvelőd is értené.

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

Kultúrális különbség. Avagy, mindenki a maga szintjén nyomorog. A környezetük erre nevelte őket. Amikor arról szólnak a hírek, hogy egy iskolás felakasztotta magát, mert rossz jegyet kapott, az is a környezete hibája általában, mert szétszekálták a hülyeségeikkel és olyan, amúgy lényegtelen dolgokat fontoskodtak életbevágónak, aminek csak a nyomorék kisközösségben tulajdonítanak óriási fontosságot, s akik fontosnak tartják, azok ezzel akarják a saját szerepüket és feladatukat óriási fontosságúvá emelni.

1. mondat:

Nekik (PUF) kb. annyiból állt a "világ" - és azt vették el tőlük képletesen is és fizikailag is (üveggolyó einstand) a vörösingesek. Azaz nekik pont hogy nem X. rendű a probléma.

2. mondat:

Milyen kisbetűs unixos usernév? Hagyomány vs kötelezőség. Hint: UNIXokon lehet vegyes karakteres a loginnév. Tény, hogy mikor a rendszert anno kitalálták, még elő-elő fordulhatott olyan beviteli eszköz, ami csak NAGYBETŰ bevitelét támogatta - e miatt a klasszik UNIX login procedúra elején a getty a csupa nagybetűs loginnév érkeztekor átkapcsolt (stty iuclc olcuc xcase = stty lcase) konverziós üzemmódba (Linuxon tudtommal már nem csinál ilyet).

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

Hol tart már a tudomány!

Amúgy biztos vagy ebben? Valamelyik korábbi Windowson ezt biztosan csak két lépésben lehetett (Nemecsek.jpg -> nemecse.jpg -> nemecsek.jpg stílusban.) Vagy lehet, hogy nem is annyira win-verzió, mint NTFS vs FAT különbség? Szerintem inkább ez.

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

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.

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

Pontosan ugyanazért, amiért különböző a konyvelés2024.xls, a könyvéles2024.xls. a könyvelés 2024.xls, a konyvelés_2024.xls, ...

A user space program figyelhet erre és figyelmeztetheti a droidot, hogy van hasonló nevű fájl, biztos újat akar létrehozni?

Csak próbálkozok ezt megérteni.

Ha egy átlagfelhasználó hús-vér ember elment egy xls-t Könyvelés2024.xls néven, akkor hol találkozik olyannal, hogy a könyvelés2024.xls jön vele szembe és ekkor tök jó, hogy az a Könyvelés2024.xls fájl lesz, amit a könyvelés2024.xls néven elér?

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.

Mert nem ugyanaz a neve? :D

Ilyen alapon hozhatnád, hogy de legyen a konyveles2024.xls is ugyanaz a file, hiszen csak az ékezet mentes verzió. De a konyvelesMMXXIV.xls is ugyanezt jelenti... Akkor meg miért nem lehet már konyvelesmmxxiv.xls is... érted? :D 

érted? :D 

Én értem, szerintem te nem érted. A "könyvelés" és a "Könyvelés" ugyanaz a magyar szó. A római számok ugyan ugyanazt a jelentéstartalmat hordozzák, de baromi nehéz véletenül római számot írni az arab számok helyett. Míg a kis- és nagybetűk felcserélése elég könnyen előfordulhat, pl. telefonnal nevezed el a befotózott doksiról készült PDF-et, és a telefon automatikusan nagybetűre változtatja a textbox első karakterét.

Akkor az l és 1 vagy az O és 0 is legyen ugyanaz, ha valamely karakterkészleten tök ugyanúgy néz ki? Vagy az egymás mellett lévő betűk, mert tök könnyen félrenyomható?

Ez az érvelés nem indokolja, hogy ez a "probléma" fájlrendszer szinten legyen kezelve, esetleg azt, hogy user space szinten figyelmeztessen a hasonló nevekre.

( 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.

Azaz, és akkor jön a kínai tradicionális, és egyszerűsített jelírás, valamint pinyin-latinbetűs átirat ekvivalenciájának kérdése...

Egy kínai könyvelő számára a 會計2024.xls, a 会计2024.xls és a kuaiji2024.xls mind ugyanazt jelenti, miért is kéne, hogy az oprendszer megkülönböztesse őket... :)

Tekintve, hogy mindhármat pontosan ugyanazon billentyűsorozattal lehet begépelni...

Régóta vágyok én, az androidok mezonkincsére már!

Láttad már hogy csinálják? Ilyen autocomplete/on screen keyboard szerűség mutatja folyamatosan mi fog kijönni abból amit latin betűs szótagokként gépelnek.

Gondolom van valami üzemmódváltó hotkey, ami alapján a szoftver tudja, hogy melyik átírási móddal dolgozol éppen.

Régóta vágyok én, az androidok mezonkincsére már!

( azbest | 2025. 04. 28., h – 08:11 )

Ahogy más is említette, mivel nem egyetlen karakteródolás van használatban mindenütt, így vagy a fájlrendszernek kéne tartalmaznia és kezelnie a karakterkódolását vagy csupa szopás lenne belőle.

Amúgy ennek a párja win alatt meg lehetne az ékezetes mappák/fájlok. A mai napig előfordul, hogy valamelyik program azért nem működik megfelelően, mert a felhasználó nevében és a neki generálódó mappában ékezet van. Az ms-nél az online belépésesre létrehozott fióknál lehet ezért sem a felhasználó nevét használják a home könyvtár neveként, hanem egy levágott, átalakított szót. De offline fiókkal létrehozott userként még mindig megesik, hogy bajt okoz ha valakinek nem angol neve van (erre pl workaround, hogy "user" néven hozom létre a felhasználót és utána a felhasználókezelő rendszertoolban a látható nevet írom át ékezetesre).

( OnlyZaenae | 2025. 04. 28., h – 11:03 )

Most akkor ki kivel van? Ki az aki a sensitive és ki az aki az insensitive megoldást támogatja? Elvesztem a hozzászólások tömegében.

Talán még szavazást is lehetne kiírni. Persze az névtelen, a hup nem támogatja a névvel történő szavazást. Vagy rosszul tudom?

Még nincs aláírásom.

( tsamu | 2025. 04. 28., h – 17:23 )

more from this thread:

From: Linus Torvalds <torvalds@linux-foundation.org>

----

.....

99.9% of the time, you just wasted enormous amounts of
time, because you could have done the comparison first *without* any
normalization at all, because equality is equality even when neither
side is normalized.

And the *common* case is that you are comparing things that are in the
same form. For example, in filesystem operations, 99.999% of the time
when you do a 'stat()' the *source* of the 'stat()' is typically a
'readdir()' operation. So you are going to be using the same exact
form that the filesystem ALREADY HAD, and it's going to be an exact
match, and there will NEVER EVER be any case folding issues in those
situations.

But the "simplistic" way to do it is to always normalize - which
involves allocating temporary storage for the new form, doing a fairly
expensive transformation including case folding, and then comparing
those things.

Christ.

The pure and incompetence in case-insensitivity *hurts*.

And what is so sad is that all of this is self-inflicted damage by
filesystem people who SHOULD NOT HAVE DONE THE COMPLEXITY IN THE FIRST
PLACE!

It's a classic case of

  "Doctor, doctor, it hurts when I hit myself in the balls with this hammer"

----