Az APFS jelenleg használhatatlan a legtöbb nem angol nyelvvel

Fájlrendszer, NAS, storage

Az Apple File System (APFS) egy, az Apple által a macOS-hez, iOS-hez, tvOS-hez stb. fejlesztett fájlrendszer. A hírek szerint az APFS-nek jelenleg gondja van az Unicode-dal és csak limitált ASCII karakterkészlettel lehet biztonságosan használni. Ennek biztonsági következményei is lehetnek. Részletek itt.

( tntwormz | 2017. 06. 09., p – 23:06 )

Elolvastam a cikket, és szerintem nem arről van szó, hogy ne lenne rendes Unicode támogatás, hanem az, hogy nincs egy olyan kényelmi funkció, ami korábban volt. A cikk alapján a HFS eddig tartalmazott egy "normalizációt", aminek a segítségével a hasonló ékezetes karaktereket nem engedte létrehozni egy új file nevében. Pl. lehet két file-t készíteni így:

café.txt (C3 A9)
café.txt (CC 81)

Ilyen café-s trükköt el lehet linuxos fájlrendszereken is sütni, meg domainregisztrálásnál, és még sincs tiltva, pedig egyértelmű, hogy biztonsági kockázat.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Igazából nem a filerendszerrel van a probléma, hanem azzal, hogy eddig a userspace programok építettek a normalizációra, ezt most kihagyták, viszont a userspacet nem húzták utána. Szerintem az elég gáz (lásd linket cikk), hogy a finderben látsz egy filet, de nem tudsz vele semmit csinálni, illetve az is, hogy még csak egy sima rm paraccsal sem tudsz közvetlenül törölni bizonyos fileneveket.
Ilyen problémák linux alatt nincsenek.
Értelmezésem szerint tehát a címet inkább úgy fogalmaznám, hogy a userspace problémái miatt az apfs használata jelenleg erősen problémás lehet.

Milyen nulla elterjedtség?
https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Market_s…
Oké, desktop tekintetében a harmada (de nem nulla), minden máshol meg 28-99% - ez azért erősen nem nulla.
KAMI | 神
Linux Mint: https://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes

„Érdemes lenne a cikkben megemlíteni hogy az összes linuxos fájlrendszer használhatatlan. Vagy ez azért nem fontos mert közel nulla elterjedtségű?”

Egyetértek, ez egy nulla elterjedtségű, teljesen halott platform, a kutyát sem érdekel. Csak a koliban akarnak a hupperek is villogni. Ez van, pár marék nerd.

Erről a használhatatlanságról írhatnál részelteket, nekem épp az ellenkezője jött le hozamosabb linuxozásnál, nevezetesen, hogy a linuxos fájlrendszerek ufótechnológia az elavult, töredező, belassuló, apró fájlokat lassan kezelő, szarul cache-elhető NTFS-hez képest. Ha meg esetleg az ZFS-re céloztál, akkor az meg megint van Linuxra is.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Azt én sem igazán értem, hogy miért pont egy filesystem esetén aggodalmaskodik a cikk írója, amikor ehhez többnyire neki kell begépelni a file nevét, és nem valószínű, hogy kétféle "é" van a billentyűzeten...

De nagyon jó, hogy irtad, mert a domain név az egészen más probléma, mert ott általában passzív módon csak kattintgatunk, ezért egy ilyen hasonlóság komoly biztonsági kockázat lehet.

Az é betű csak egy van. A lejánykori neve: LATIN SMALL LETTER E WITH ACUTE.
Van egy olyan group, amit meg így hívnak: Combining characters.
Ebben az esetben az é betű álnevet vesz fel: COMBINING ACUTE ACCENT. (e+'=é)
Ennek nyilván sok értelme van. ;)

Magyarázom. A 80-as évek elejétől nyomtató fejlesztésen dolgoztam. Ismertük már a PostScript-et is. A kínai (és számunkra kínai:)) karakterkészletektől eltekintve, azaz a latin és ciril "karakter származékokat" tekintve a világ nemzeti karakterkészletet tartalmazó kódlapokban egyetlen combining character volt. A második tagja amit nem tudtak másképp elnevezni a HUNGARUMLAUT. (", azaz o+"=ő, illetve u+"=ű).

Nomármost egy fájlnév írásakor egy LANG környezetben keletkezik a név. Pl. unicode -> iso8859-2 átalakításkor az iconv minden bizonnyal az különböző kódolású é betűket az "egyszerűbbre" fogja alakítani. Felmerül a kérdés, hogy miért egy filesystem segítségével akarunk valami olyat megoldani, ami a LANG környezet feladata lenne. Avagy a bármely LANG környezetből érkező karakterek miként kerülhetnek a második formátumban a diszkre?

A problémakör valahogyan a unicode használhatatlanságát mutatja. Nem lenne szabad egy dokumentum belsejében előforduló dolgokat fájlnévbe írni. Ellenkező esetben mindig lehetséges olyan konstellációt létrehozni, amikor a konverzió nem egyértelmű, azaz a rendszer használhatatlanná válik.

Combining esetén a String.Length() egy elég macerás dolog.
Viszont a combining nagyon jól jön, ha pl. magyar szabvány szerinti bibliográfiai rendezést csinálsz, és nem akarsz felkészülni az összes lehetőségre, hanem simán hagyatkozol a keretrendszer Unicode támogatására (és bízol benne, hogy jó :).

A cz-vel nem, mert olyan a magyarban nincs. Igen, tudom, külön figyelni kell a kettős-hármas írásjelekre, sőt ezek dupláira külön (tudni kell, hogy az „ssz” s-sz vagy sz-sz, ezeket szótárazom), bónuszként szintén figyelni kell az ő-ű betűkre, mert azokat meg nem szabad combiningként kezelni, mert a szabvány szerint nem o/u+mellékjel.

Győztél, de nem. A példa jó, csak gondolkodás nélkül írtam. Betűrendbe soroláskor a két- és háromjegyű mássalhangzókat különállóknak kell tekinteni (azaz például a Czentár után következik a Csaba)...
Szóval a szótárazás az kell, viszont nélküle az unicode nem sok segítséget ad. Ezért is értelmetlen a magyar nyelvű oprendszer - a fálnevek rendezése mindig kiveri a biztit.
Az ő és ű kezelhető combiningként, hiszen ö+"=ő. Csak ezt nehéz befogadni olyannak, aki az a hangot sem képes helyesen kiejteni. :) Mert lássuk be, hogy a combining csak egy absztraktció. A valóságban meg csak a nyomtató/írógép/repülőékezet működését szimulálja - ezek meg vasból és műanyagból vannak, de semm közük bármilyen kódhoz. A hosszú magánhangzó ilyen jelölése meg csak nem magyar anyanyelvűnek szokatlan.
A sok zagyvaság helyett: a combining egy betű fizikai összerakása két jelből. Az magyar nyelvben meg a kiejtés szerinti módosító. Mivel ö van más nyelvben is, ezért lett a hungarumlaut kakukktojás.

Már rég elkanyarodtunk a fájlrendszer témájától, én spec. a rendezésről beszéltem.
A Unicode a rendezésnél ott segít, hogy miután megvannak a magyar betűk (közöttük az ő, ű), a maradékkal is kell kezdenem valamit. És nem kell nekem kell kitalálnom, hanem fogok egy Unicode-ot ismerő libraryt, az aktuális karaktert normalizálom NFD-be, veszem a string első karakterét, besorolom az ékezetmentes mögé, aztán az összehasonlítás folytatódik a mellékjelek sorrendje szerint. (Ja, és csak a poén kedvéért: ha magyar neveket kell rendezni, és becsúszik egy-két külföldi, akkor az ö-ő előbb van, mint az ô, vegyes névhalmaznál viszont később.)

A témához kapcsolódóan: egyébként nem is értem, hogy a búsba fordulhat elő, hogy szöveges adat tárolásánál a nem kanonikus forma megengedett, de ki vagyok én, hogy az Apple-t kritizáljam? :)

hiszen ö+"=ő.

NEM! o+"=ő (pontosabban: o+̋ =ő :)

Lefordítom amit írtál. Rendezésnél szükséged van
- sort order táblázatra (szigorúan monoton növekvő értékek: ... e é f g gy ...)
- sort weigth táblázatra (monoton növekvő értékek: ... {e é} f g ...)
- a fentiekhez definiálni kell a karakter szekvenciákat is: cs, dz, gy, stb.
- szótárazni kell a speciális értékeket: a cs mikor cs és mikor c+s
- a fentiekhez az adattartalomtól/alkalmazástól függő kivételeket is meg kell adni
- sőt, még az egyes "kényszer" konverziókat is, pl. ß->ss
Ez a "betűrendbe szedés", vagy a névsor szerkesztés. Így működik a tudakozó és a telefonkönyv is.

Ennek ott van köze a fájlrendszerhez, hogy minek erőltetni a "minden karakter ábrázolási képességet", ha a fenti eszközkészlet hiányában úgy is hibás lesz az eredmény!? Sokkal rosszabb a helyzet, ha heterogén forrásból származó - néhol hibás adatokat - próbálsz meg vegyíteni a mindentudó unicode segítségével.

Az ő betű szitetizálásánál azt próbálom magyarázni, hogy el kellene már felejteni a történelmet! Az Unicode 1.0.0 születésekor még nem igazán terjedtek el a nonimpact nyomtatók. A combining csak azt írja le, hogy ha
- az éppen használt kódlap nem tartalmaz egy betűt, vagy ha
- az adott nyomtató (pl. sornyomtató, daisywheel nyomtató/írógép) fizkailag nem tud egy betűt,
akkor hogyan lehet - esetleg - összerakni kettőből. Ennek ma gyakorlatilag nulla a haszna.
Az egyszerű karakteres esetben a combining lapot el lehet felejteni, illetve régi anyagok feldolgozása esetén először konvertálni kell egyszerűbb alakra!

Ez is igaz.
Erre pedig pontosan ezt írtam: Ennek ott van köze a fájlrendszerhez, hogy minek erőltetni a "minden karakter ábrázolási képességet", ha a fenti eszközkészlet hiányában úgy is hibás lesz az eredmény!?

Lefordítom: A filerendszer csak egyszerű karakteres rendezést fog tudni. Tehát minek erőltetni a pl. magyar fájlneveket, amikor nyelvi szempontból hibásan rendez?

Szerinted én nem értek valamit? ;)

Még egyszer: a filerendszernek nem feladata, hogy bármilyen szempontból rendezzen. Nem is teszi: 

$ touch 1 2 3
$ find
.
./2
./1
./3

Egyszerűen csak listázza a fileneveket olyan sorrendben, ahogy neki kényelmesebb. Az már a userland processzekre tartozik, hogy ezeket rendezik-e vagy sem, és ha igen, akkor mi alapján (név, méret, utolsó módosítás időpontja, ...).

Másrészt pedig attól, hogy valaki magyar ékezetes karaktereket tesz a filenevekbe (vagy bármilyen más ékezeteket, vagy akár egyéb sokbyte-os unicode karaktereket), még nem biztos, hogy érdekli, hogy nyelvi szempontból, magyar szabvány szerint helyesen vagy hibásan rendezi őket a fileneveket megjelenítő eszköz (ls, find, mc, windows intéző, stb.).

( NevemTeve | 2017. 06. 11., v – 13:28 )

A haladó megoldás az lenne, ha az ilyen nem-ASCII nevű fájlokat azonnal törölné valami automatizmus... Húsz-harminc ilyen eset után a legbutább usernek is derengene, hogy nem kellene erőltetni...

( zsoltt | 2017. 06. 11., v – 19:45 )

Írja a cikk, csak valahogy nem hangsúlyozza, hogy a leírt probléma case insensitive esetben van csak. Nagyon ritka, hogy valaki case insensitivera formázta volna eddig is a HFS+ -t, és APFS -ből is case insensitive a default.