( dlaszlo | 2025. 04. 27., v – 22:51 )

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.