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.

Oké, de akkor a mi a helyzet a kovacs_janos.pdf -el, vagy a kovács jános.doc és a kovács jános.docx állományokkal, valamint a János Kovács.doc ? És a kovás jancsi.docx? ezek közül melyek ugyanazok, és miért? Itt már jönnek a nyelvtani hitviták, aztán az adott országban hatályos nyelvtani változásokkal változnia kéne az egyezőségi mátrixnak is, nade akkor is, ha egy másik országba viszik át az adathordozót?

Ezek már ilyen emberi dolgok, ezeket nem az adattárolás szintjén kéne megoldani.

Dehogy ellentmondás.

De, attól még ellentmondás (a fontos-e a kis-nagy betű vagy sem kérdése), hogy Neked bizonyos szituációkban hasznos, máskor meg nem. Ha mentéskor fontos valami szempont, akkor ott kellene figyelni. Ahogy  YleGreg is rámutatott lentebb, nem a kis-nagy betű különbség az igazán fontos, hanem az, hogy van-e hasonló. Ennek meg tároláshoz nincs köze.

Pl. Van Kovács János.pdf-ed és el akarsz menteni egy Kovacs Janos.pdf-et. Ilyenkor szólhat a rendszer, hogy van már hasonló:

  • felül akarod írni,
  • a megadott néven menteni,
  • mégsem.

Így itt van a szabadság is és az általatok kért vizsgálatnál (kis-nagy betű különbség) sokkal jobb módszer.

Akik ennyire kardoskodnak a case-sensitive filerendszerek mellett, mit szólnának ahhoz, ha az email címek is case-sensitive-ek lennének? Kérdezhetném a login neveket, de ott - ahogy látom - elég nagy a káosz, van rendszer, amelyik case-sensitive login neveket használ, és van, amelyik case-insensitive-et. A logika ugyanaz mögötte, ha személynevekről van szó.

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

Nem a MS találta ki, de ők azok, akik ebben a formában kötelezően tolják rá mindenkire. Linux alatt általában ilyet nem látni, hogy rendszerfájlokban, rendszermappákban szóköz legyen, de netről töltött anyagokban gyakori, e-könyv, zenei album, háttérkép, git clone-ozott tárolókban, stb. elég sűrűn előjön szóközös mappa vagy fájlnév. Még átnevezni sem lehet mindig, mert ha a Makefile vagy a torrentkliens megadott néven keresi, akkor nem lehet alóla kihúzni a szőnyeget, mert nem fogja megtalálni az adatot.

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

Elég sokszor látok Linux alatt is szóközt file-nevekben, elvégre miért ne? Nem véletlen, hogy shellscriptekben idézőjelek közé teszik azokat a változóneveket, ahol előfordulhatnak file-nevek.

Igaz, hogy nem Linux, hanem Unix, de pl. a Mac esetében a rendszerlemez neve 'Macintosh HD', ott van a /Volumes alatt :)

Ha KDE filekezelővel (Dolphin) új könyvtárat hozol létre (magyar locale esetén), akkor 'Új Mappa' lesz a default név, de a különféle file létrehozása is jellemzően szóközzel megy alapból.

A szabadság. Szeretem az általános megoldásokat, nem szeretem az önkényes korlátozásokat. Miért ne lehetne newline, szóköz, akármi?

Például a gépemen van egy C: nevű symlink, ami a .wine/drive_c alkönyvtárra mutat. Örülök annak, hogy case-sensitive, mert ez nagy C-vel kifejező, és annak is, hogy a kettőspont megengedett, mert így azonnal tudom, mit értsek rajta.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Persze. Megmutattam egy kollégámnak, hogy Linuxon ez sem probléma. :) Egyébként a különféle karakterek tiltásával az a baj, hogy akkor tudnod kell, mit nem használhatsz, s ha nem tudod, használod, marad a hibaüzenetet követő szentségelés. Miközben semmi akadálya annak, hogy a filerendszer kezelje majdnem az összes karaktert. Mint ahogyan az ext4 kezeli is.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Számít bármit is? A futtathatóság jogosultságon múlik, semmi köze a névhez. Én amúgy tiszta szívből vallom, hogy a file-oknak nevük van, s nincs olyan, hogy kiterjesztés. Ha egy valami.jpg file-t átnevezek valami.mp3 névre, attól az még kép marad, s ugyanúgy a képnézegetővel fogom nézni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kb emiatt jött létre ez a vicces bug is: https://beza1e1.tuxen.de/lore/print_on_tuesday.html
Ezzel nem azt mondom hogy a kiterjesztés jobb mint a file header/magic byte alapú megközelítés, talán valami extended attribútumban lehetne a legjobban ezt tárolni -- azzal meg a kompatibilitás lenne agyonütve.

Pedig tényleg azt kéne csinálni, hogy a metaadatot (az, hogy milyen típusú a fájl) azt egy külön attribútumban kell tárolni, mondjuk MIME típusleíróval. Igazából a fájl tartalmán kívül mindene metaadat, a neve is, a rá vonatkozó jogosultsági beállítások is, a típusa is.

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

Tudom, hogy nem beszélt senki a file-ok tartalmáról. Pusztán a logikája ugyanaz. C-ben az alma és az Alma nevű változó, függvény, makró különbözőek, és ez így van jól. Így tudnak kialakulni olyan szokások, hogy a makrók és enum konstansok tipikusan csupa nagybetűk, változók jellemzően kicsik, de ez sem kötelező.

A filenév és alkönyvtár pontosan ilyen. Az alma és Alma két különböző file.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A filenév és alkönyvtár pontosan ilyen. Az alma és Alma két különböző file.

Tudsz egy példát mondani erre?

Mert a te felvetésedre én tudok. C#-ban a konvenció az, hogy az Alma az osztály neve, az alma pedig az abból példányosított objektumé. Te tudsz hasonlóan életszerű példát az alma és Alma fájlokra?

: >alma
mkdir alma
mkdir: cannot create directory ‘alma’: File exists
mkdir Alma
ls -l
-rw-rw-r--. 1 locsemege locsemege    0 May  1 12:16 alma
drwxrwxr-x. 2 locsemege locsemege 4096 May  1 12:17 Alma

Például. Hasonló névvel kellene alkönyvtár és file, de case-insensitive esetben jön majd, hogy tegyünk elé alulvonalat vagy szóközt, de jaj, lehet, hogy ez utóbbit sem lehet, mert csak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE