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

A számítás költsége egyáltalán nem elhanyagolható. Ha sok kis fájlra nyomsz egy git status-t, akkor érezhetően számíthat. Vagy egy szerveren ami sok fájlból szolgál ki kéréseket. Ezért is mondom, hogy bájt tömb legyen a fájlnév! Mindenféle karakter konverziós zsonglőrködés értelmetlen a fájlrendszer szintjén. Azt a userspace-ben kell kezelni.

Oké, hogy byte tömb, de milyen enkódolás szerint? Unicode karakterek UTF-8-ra kódolva? Unicode karakterek UTF-16-ban? Vagy EBCDIC? Vagy csak ASCII?

A diszken mindig minden bytesorozat, semmi más nincs, ezzel sokat nem mondtál.

Na de a nagy kérdés mindig az, hogy a userspace mit képezzen le és hogyan, bytesorozatokra? A fájlrendszer, ha hordozható, akkor ezt előírja (pl. minden esetben Unicode 10 karakterek vannak UTF-8 kódolva), és ekkor minden eszköz, ami ezt a fájlrendszert csatolja, akkor jól fogja csatolni. Amikor már bejön az, hogy userspace-re van ez bízva, akkor jönnek elő az inkompatibilitási gondok: egyik OS userspace ezt jól implementálja, a másik nem stb.

Dehogy ellentmondás.

Például ha neked mondjuk önéletrajzokat kell gyűjtened, akkor nem rossz az, ha úgy néz ki, hogy Kovács János.pdf, és nem tudod létrehozni már a KOVÁCS JÁNOS.pdf-et, mert az ugyanazt jelenti igazából. És ne legyen kovács jános.pdf, mégis egy tulajdonnévről van szó - engedje meg a gép, hogy helyesen írjunk.

A számítógép van értünk, és nem mi a számítógépekért. És az emberi világban a KOVÁCS JÁNOS meg a Kovács János ugyanazt jelenti, a csupa nagybetűs név az csak egy írásmód. 

Szóval nagyon is jó az, ha a fájrendszer tudja, hogy hol van kis/nagybetű a fájlokban, és meg is jeleníti ezt a felhasználónak, és azt is tudja, hogy összehasonlításkor, kereséskor, létezés vizsgálatakor viszont case-insensitive-nek kell lenni, mert az emberek fejben nem kis/nagybetűkben gondolkodnak, az csak helyesírás, hogy mikor írunk valamit nagybetűvel.

És még egyszer: a gép van értünk, nem mi a gépért. A gép kövesse le az emberi logikát.

Szóval van olyan használati eset, hogy case-insensitive működés kell (mert az emberek így gondolkodnak), de számít, hogy hol van nagybetű, mert a helyesírást is illik betartani, fájlnevekben is.

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

Szerkesztve: 2025. 04. 29., k – 12:09

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?

De ha a teljesen idióta felhasználók kiszolgálása a cél, akkor kérném a filerendszer fejlesztőket, hogy tegyék lehetővé, hogy a vár.jpg mellé (ami egy fotó a budai várról) tehessem a vár.jpg állományt, amin a kajára váró macskás kép van. Hiszen ez tagadhatatlanul két teljesen külön dolog. Ennyi.

Igen, képtelenek különbséget tenni, mert nem gondolják, hogy ez különbség lehet. Egyébként pont a saját érveid szólnak az insensitive mellett:

" 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." - igaz, mekkora hülyeség? Na, ugyanilyen hülyeség az usernek, hogy az Alma.txt és az alma.txt két különöbző fájl lehet. Van még itt másik hozzászólás, hogy nem elég egzakt az insensitive, szerintem pont az nem egzakt, hogy létezik Alma.txt meg alma.txt is ugyanabban a mappában.

"De ha a teljesen idióta felhasználók kiszolgálása a cél, akkor kérném a filerendszer fejlesztőket, hogy tegyék lehetővé, hogy a vár.jpg mellé (ami egy fotó a budai várról) tehessem a vár.jpg állományt, amin a kajára váró macskás kép van." - igaz, ez is mekkora hülyeség? ne legyen ilyen! amikor azt mondom, hogy a vár.jpg-t másold le nekem, akkor ne legyen abból félreértés, hogy a Vár.jpg-t vagy a vár.jpg-t kérem valójában.

Az, hogy lehet "Üzleti kimutatás 2025 Q3.ppt" meg "Üzleti Kimutatás 2025 Q3.ppt" ugyanabban a mappában, csak trollkodásra jó, semmi másra a világon.

Akkor ne lehessen egy mappában 'üzleti kimutatás 2025 Q3.ppt' és 'üzleti kimutatás 2025 Q4.ppt' sem, hiszen ezek ugyanúgy egy karakterben különböznek, és a manager úr titkátnője esetleg nem érti a különbséget? :))

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

Igen, valami ilyesmit papol Linus is, csak itt a túlnyomó többség mintha nem értené (vagy nem olvasta): az insensitive esetben információ veszik a fájlnév megadás (nem 1-1 megfeleltetés) és/vagy visszamutatás/megjelenítés (nem megjeleníthető ill ugyanolyan képű karakterek a kódrendszerben) során is, amit rosszindulatúan is ki lehet használni -> félreértések, pontatlanságok, biztonsági problémák + komplexitás és overhead.

( BehringerZoltan | 2025. 04. 28., h – 20:32 )

Nem lehetne szöveg helyett kép? Ikonok? Akkor az analfabéták is tudnák használni! 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Ikonok (kiskép) jó régóta vannak, igazából már majdnem ott vagyunk amire gondolsz (általános hangalapú pc használat), csak még kicsit a hardvernek kellene fejlődni, hogy ne fűtsön annyira az AI és lemenjen a kezdeti kopasztásos fázis (online szolgáltatás, drága és sok hardver). Amint valaki bedobna egy dzsunkacsipet (occó, pici), ami bír futtatni normálisan a saját eszközön egy angolul beszélő asszisztenst - az összes menő oprendszerbe bekerülne a "teljes" integráció. Csak hát úgy néz ki, hogy ez senkinek nem érdeke, mert vaseladásból meg előfizetésből lehet jól megélni. :/

Belegondolva, a telefongyártók vannak a "jó" vonalon - ami nem csoda.

( dyra | 2025. 04. 29., k – 03:05 )

Mindenki megszokta már ezt. Baromi nehéz lenne rajta változtatni. 

( gabek | 2025. 04. 29., k – 13:15 )

Mi az érv a case sensitive mellett? Ugyanis a "valami.docx" "Valami.docx" meg a "vAlami.docx" közötti különbségtétel a trollkodáson kívül nem igazán sok mindenre jó.

Ha csak a file nevnel maradsz, akkor a következő esetben.

Van egy forrasod, ami fölött semmi kontrollod nincs. extra repo, program, stb.  a fileok éppen case-sensitive mode-ban vannak.

Na most akkor masold/toltsd le ezeket a fileokat a sajat case-insensitive filerendszeredre. (pl.: xfs-> fat32)

 

Masik szenario: generaljon neked valami random file neveket, legyen ez a program case sensitive, ne legyen kontrollod felette, aztan lehet hajat tepni, hogy 300,000 file-bol miert van 1-2 ami valami okbol kifolyolag nincs meg.

Kolléga szepen belefutott egy ilyenbe amikor salesforce objecteket szeretett volna kiirni sima fileokba (ne kerdezd miért, en se ertem). Úgy döntött,hogy a filenevek az object id-k lesznek es mindent kisbetusre alakít ;)  .... nem sult el jól.

 

Sokszor nem az a baj, hogy neked nem kell, hanem az hogy a világ rajtad kívül értékeli es hasznalja is a case sensitive modot.

Support Slackware: https://paypal.me/volkerdi

( gazsiazasz | 2025. 04. 29., k – 17:01 )

Érdekes, az épül meg tudta csinálni, lájnusz ne nyekeregjen, csinálja meg!