A fájlrendszer legyen ....

Fájlrendszer, NAS, storage

Előzmények: Linus Torvalds kifejezte gyűlöletét a case-insensitive fájlrendszerek iránt

( ggallo | 2025. 04. 28., h – 12:11 )

Szerkesztve: 2025. 04. 28., h – 12:17

Én a case-insensitive-re szavaztam. Nem meggyőződésből, nyitott vagyok a témában. Pontosabban azt szeretem, ha nem nagybetű-kisbetű érzékeny, de úgy tárolja és jeleníti meg, ahogy beírom (hogy kellemes legyen olvasni).

Édekelne, hogy aki szerint a case-sensitive a jobb, azt miért gondolja ezt? Szerintem kifejezetten zavaró és problémát/félreértést okozhat, ha az ABC.txt és az abc.txt két különböző tartalmú állomány lehet azonos mappában. Az persze tény, hogy biztosan vannak ellenérvek, amiket nem ismerek, ezért kérdem.

Szerk.:
Elolvasva sok kommentet, értem, hogy műszakilag tutibb a case-sensitive, mert nem lesznek problémák az átalakítás során.
De felhasználói oldalról meg pont az érzéketlen a "kényelmesebb" - szerintem.

Édekelne, hogy aki szerint a case-sensitive a jobb, azt miért gondolja ezt?

Mert a case-insensitive nem implementálható jól, nem is lehet hordozhatóra megcsinálni, ugyanis erősen lokalizáció függő. Másik szálban is írtam, 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). Na ezért.

Csinálnál két fájlt, az egyik neve "ınsesitive", a másik neve "insensitive", na ez egy magyar Windows-on két külön fájlnak minősül, ellenben egy török Windowsnak ugyanazt a fájlt jelenti. Szopás a köbön a case-insensitive, még akkor is, ha nem bugos az implementáció, márpedig Linus pont azért kelt ki, mert még ráadásul rosszul is van általában implementálva.

Csak azért hoztam pont ezt példának, mert folyton látom, hogy mindig, mindenhol szopnak vele, mint a torkosborz, tele a github ilyen hibajegyekkel (projekt tökmindegy):
Uppercase/Lowercase conversion causes crash in Turkish locale (rwtema)
lowercase(String) doesn't handle case transformation contexts correctly (Julia)
string.lowercase/uppercase/letters not affected by locale changes on linux (Python)
Uppercase & Lowercase is not working on Turkish Characters (Perl)
Locale/language-sensitive case mapping ("Whats wrong with Turkey?") (Rust)
Türkçe karakter dönüşümü yapabileceğiniz PHP fonksiyon (PHP)
... stb.

Nyilván nem a török i az egyetlen problémás eset, csak ezt szokták a leggyakrabban reportolni. A teljes lista egyébként itt található, ráadásul a lista állandóan változik, csak hogy örüljünk... (legutóbb két hete frissítette a UNICODE).

nameg olyan szopasok hogyha ezt a ket fajlt itthon egy pendriveon csinalod, majd azt atviszed egy masik helyere (pl azerbajdzsanba) akkor a ket fajlt kozul melyiket fogja ott olvasni a "TYPE INSENSITIVE" parancs?

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ha szerinted ha anyukad keresztevet csupa kisbetuvel irod az ugyanaz, mintha nagy kezdobetuvel tenned, akkor a case insensitive filesystem neked lett kitalalva. 

En akarhogy nezem nekem az "abc" nem ugyanaz mint az "Abc" vagy az "ABC". Nem is ertem mitol lenne ugyanaz. Tok mas. Ez olyan mintha azt mondananak, hogy a Mona Lisa ugyanaz, mint amit a lanyom 2 evesen rajzolt onarckepet. Mind a ketto egy noi fej, de azert zongorazni lehet a kulonbseget a ket produktum kozott, megha imadom is a lanyom rajzait :D

( Honkydoo v | 2025. 04. 28., h – 12:15 )

Legyen case-sensitive viszont, ha keresést futtatunk, akkor nem biztos, hogy árt, ha a kereső case-insensitive.

Oké, szerintem nem túl jó dolog a case-insensitive fájlrendszer. Mert több problémát generálhat mit amennyit megold.

Ahogy írod, a keresőkben ki lehet választani, hogy  CI vagy CS legyen. Azért említettem meg, mert talán értelmesesebb ezt a problémát "magasabb rétegben" kezelni.

Egy részt +1

Más részt: Így is van csillom metadata/attribútuma egy fájlnak. Akár elférne benne egy humán kompatibilis név is.

A file neve a diszken innentől lehetne akár generált is. Aki programoz, tudni fogja, az egyszeri user meg eligazodik a metadatként tárol nevével. Utóbbi viszont case-insensive és természetesen szintén unique a könyvtáron belül.

Nem kizárt, hogy nem én találtam fel a spanyol viaszt, illetve élből ellene is tudok érvelni... (asszem jogi pályára kellett volna mennem :-D)

( azbest | 2025. 04. 28., h – 12:51 )

A gordiuszi csomó: nem fájlrendszer szinten kell megoldani az inszezitivást, annak minden veszélyével és problémájával együtt.
Hanem alkalmazás vagy opcionális wrapper réteg szinten legyen. Akkor a fájlrendszer mondhatja azt a wrapernek, hogy bocsesz, ezt nem lehet.  Az meg azt csinál az inkonzisztenciájával, amit akar, de legalábbis nem rontja el a fájrendszert.

( Friczy v | 2025. 04. 28., h – 13:49 )

A case sensitive-et tartom jobbnak, főleg, mióta mindenféle karakter megengedett a file nevekben. Persze majd kíváncsi leszek, mikor hozza valaki elő ugyanezt a DNS nevekben :) Most az az érdekes dolog van, hogy az URI-n belül a hostnév case-insensitve, a path pedig vagy igen, vagy nem :)

Nem, a DNS-ekben a hostnév definíció szerint case-insensitive.

https://www.rfc-editor.org/rfc/rfc1035#section-2.3.3

For all parts of the DNS that are part of the official protocol, all
comparisons between character strings (e.g., labels, domain names, etc.)
are done in a case-insensitive manner.

( wyx v | 2025. 04. 28., h – 15:05 )

A kinaiaknak meg a japanoknak mi a case sensitive es non-sensitive? :D

Japóknál előfordul, ha épp nem kanji-t használnak. Mondjuk sok különbség nincs köztük, alig észrevehetően nagyobbak csak kicsit a betűk, nincs más alak, de más a UNICODE kódpontjuk, szóval különbözőek.
Itt egy lista (második és ötödik oszlop a kisbetű, harmadik és hatodik oszlop a nagybetűs megfelelő).

A kínaiaknál szerintem nincs ilyen.

A japán írásban a kandzsi(szó szerinti fordításban: ~kínai írás) mellett használnak szótagírásra hiraganát és katakanát. A katakanát általában a külföldi szavak leírására használják. Pl.: 日本コカ・コーラ ~Nyihon (Nippon) Koka Kóla(*), de a ko hiraganával írva こ, katatakával meg ugye コ. Értelmezésem szerint ez áll a legközelebb az általunk megszokott kis- és nagybetűhöz. DE nincs olyan náluk, hogy a sor elején (illetve ugye náluk inkább a tetején) "nagybetűvel" kezdenek.

Aztán. Shi: し, ja: や, de a しゃ (~sa) már kajak más (kábé mint g + y, l +y, stb.). Meg még van egy vödör hasonló.

Ennek fényében ezt én nem tekinteném kis-nagybetűnek, mert... mert nem az.

Abba bele se kezdjünk, hogy mit művelnek a kandzsival :D

 

*) Igen, ezen szokott kitörni a véresszájú acsargás, hogy nem "ra", hanem "la", vagy épp fordítva. Meghallgatva pár nyelvjárást, én azt mondom, hogy attól függ. Vö.: rámen vs. lámen harc.

( _ventura_ v | 2025. 04. 28., h – 16:28 )

Csak 2 ? A case-preserving már nem menő ? vagy ma már azt a case-insensitive hez csapják ?

Fedora 41, Thinkpad x280

( asch v | 2025. 04. 28., h – 17:54 )

A fájl neve egy bájt tömb legyen. Amit a user a felhasználóbarátság jegyében ASCII vagy UTF8 stringként értelmez tetszése szerint.

( YleGreg | 2025. 04. 28., h – 19:18 )

A file rendszer feladata az, hogy adatokat tároljon, és egzaktul lehessen hivatkozni. A case insensitive nem egzakt, vagyis nem elég jó.

Mi lenne, ha a string kezelő függvények mind case insensitive-k lennének? Elvégre nem tökmindegy, hogy LOREM IPSUM vagy lorem ipsum? Vagy, hogy alma vagy ALMA? Mindkettő gyümölcs nem? Mondjuk néha nem, de biztosa találasz egy olyan könyvelőt, vagy Könyvelőt aki szerint ugyanaz, úgyhogy nosza, holnaptol minden string objektum és minden char* pointer tartalma legyen case inszenzitív, ugyan mi baj lehet belőle.

Az egész probléma abból fakad, hogy egyesek azt hiszik, hogy a file nevek szöveges adatok. Nem. Azok számok. Régen ASCII, most pedig UTF-8 értékek, de akkor is számok. Legyen a matekban a 560 ugyanannyi, mint a 785? Csak mert egy országban ez igazából tökmindegy? Hülyeség. Az egzakt hivatkozás a file listában egy azonosító, ami számok sorozata. Hogy ezt hogyan jeleníti meg a gép, az egy tök másik probléma.

Mondok egy még nagyobb baromságot: Tároljuk el azt is, hogy milyen betűtípussal van a file neve, és akkor legyen külön file a "konyveles.xls" (courier betűtipussal) és a "konyveles.xls" times new romannal, mert hát a felhasználók szerint ez a két szöveg teljesen más, csak rá kell nézni.

A case insensitive üzemmódnak semmi keresnivalója a file rendszerben. Ha akar valaki egy ilyen funkcionalitást, akkor tegyen fölé egy réteget, és kezelje ott a problémákat, de maga a file rendszer, az adatok egzakt elérése nem múlhat azon, hogy éppen milyen lokalizálás van a gépen.

Egy hálózati file insensitive filerendszer, ha 3 különböző lokalizációjú gépről van felmountolva, akkor egy lokalizáció függő file név eltérésnek szabad hazavágnia az adatokat, csak mert a felhasználók olyan plázapicsák, hogy képtelenek különbséget tenni az alma.txt és az ALMA.TXT között?