APFS: nový souborový systém Applu je optimalizovaný pro SSD, v základu šifrovaný a mnohem odolnější

Vy toho o historii filesystémů sice moc nevíte, ale doháníte to velkou fantazií :)
To chování, které popisujete (jakože má "plotny", stopy, sektory, ...), není otázkou FS, ale blokového zařízení. A samozřejmě, že filesystémy na flash paměti existovaly už dávno, na čem si myslíte, že běžel váš domácí router v době příchodu Internetu? Na malé gramofonové desce?
Jenom lidi z Windows mají pocit, že existuje FAT a NTFS, pak holt tady slyšeli o HFS a EXT. Ale že je svět FS daleko rozmanitější, že filesystém může být prakticky cokoli, to už nevidí.

filesystem sa da rozbehat na comkolvek - nad uctom gmailu, nad protokolom SMTP, kde sa vyuziva ze nedorucitelny mail sa vrati odosielatelovi, ... ak by si chcel, filesystem rozbehas nad vrecom zemiakov a par elektrodach.Ako pisal kolega nad/pod - o FS tusis menej ako srnka co prave vybehla z lesa

neumis pouzit google?

A univerzalni tlacitko s napisem HOTOVO by jste nechtel....

No tady má máslo na hlavě Apple, protože NTFS je mnohem modernější než HFS a ta změna nepřišla za pět minut dvanáct, ale spíš pět minut po dvanácté.

A jake jsou tedy dopady tohoto prichodu pozde?

Tak ciste z logiky veci, AhoJ.TXT != Ahoj.txt, pokud FS tvrdi ze ano tak je to pekna zhovadilost...Vede to pak k cunacinam napr kdyz portujes win hru na linux tak v datech mas:
Image1.JPEG
SOUND.ogg
a ve zdrojacich/scriptech mas:
image1.jpeg
sound.OGG
Coz je samozrejme prasarna na kazdem FS ktera na CI funguje na CS nePokud chces aby CS FS nepletl BFU, tak vytvareni souboru a kontrolu CI nazvu souboru ma resit spravce souboru, ne FS

Dobre, ale obecne mi neprijde vyhodne, ale spis zvlastni mit v systemu soubory aHoj.txt, ahoj.txt, Ahoj.txt, ahoj.Txt a jsou to 4 ruzne soubory. Chapu ze z pohledu stringu tu nejde o rovnost, ale z pohledu na to, ze jsou to soubory mi to proste prijde divne a matouci. Kdyz by sme to brali tak logicky, tak by taky melo byt www.zive.cz neco zcela jineho nez www.Zive.cz, kdyby to tak bylo bylo by to dost matouci.

Názor byl 2× upraven, naposled 16. 06. 2016 13:56

Divny je to pro tebe jen protoze to rekl kdysi davno M$, ze je normalni CI.

Nejde tu o MS, ale spis o to, ze v tom vidim spis komplikace nez vyhody mit CS, chapu ze "d" != "D", ale vznika pak chaos, jak jsem nize uz psal, kdyby bylo vse CS a napriklad email, kdyby michal.divis@email.cz, Michal.divis@email.cz, michal.divis@Email.cz, michal.divIs@email.cz etc. byly vzdy ruzne emailove adresy, bude to chaos. Zatim mi tu rikate, jen ze je to normalni a ze "d" != "D", bohuzel ne vzdy jde delat vse dokonale pedantsky, nekdy to taky musi byt user-friendly, a proto se tu ptam na ty skutecne vyhody CS...?Dale chapu, ze je lepsi to resit az na strane samotneho systemu a ne primo v FS, jen proste chci vedet, proc to podle vas je vyhodne?

Názor byl 2× upraven, naposled 16. 06. 2016 14:56

Ach jo... zkus se na tom chvili zamyslet:
1) S FS pracuji aplikace, ne uzivatel (takze tady je vyhodnejsi pouzit CS)
2) S aplikacemi pracuji uzivatele, uzivatel pracuje se spravcem souboru, spravce souboru pracuje s FS (a tady to pak muze rozhodnout vyvojar spravce souboru co bude lepsi pouzit)Co zpusobuje CI FS za problemy pri vyvoji/portovani aplikaci :
- Bordel v nazvech souboru na FS VS ve zdrojovem kodu, existuji pak tuny aplikaci ktere na CS FS nebudou fungovat protoze jeji vyvojari jsou hovada a nemaji zadnou kulturu v nazvech souboru a jsou jeste tak tupi ze nezvladnou onen nazev souboru napsat spravne... Viz v diskuzi uvedeny Adobe produkt a tuna win apps (Uzil jsem si sve pri portovani UE4)- Dejme tomu ze mame teoretickou aplikaci ktera si vytvari vlastni TMP soubory a pro nazvy souboru se pouziva algoritmus ktery pocita s tim ze pobezi na CS FS... co se pak stane kdyz pouziji CI FS a nebudu si kontrolovat jestli soubor jiz existuje (seznam souboru si treba budu udrzovat v CS databazi UNIQUE sloupci) vygeneruji soubor AbCd.tmp a potom aBcD.tmp s jinym obsahem co se stane na CI a CS FS ? na CI se mi prvni soubor prepise druhym, na CS bude vse OKFS proste "user-friendly" byt nemusi, protoze s nim zadne BFU primo nepracuje... a na urovni FS CI prinasi vice problemu nez uzitku a CI na teto vrstve nema co delatPS: Emailova adresa je dle RFC CS! ale samozrejme se nasla tuna BFU kteri psali Franta.Novak@example.com tak vsechny mailservery delaji naprosto jednoduchou vec, emailovou adresu prevedou na lowercase a uvnitr pracuji s CS... a zde je to naprosto opravnena uprava protoze zadani emailu je primo vstup od uzivatele. Samozrejme lepsi by bylo email v RFC definovat jako lowercase a kontrolovat to v emailovych klientech, pak by byl klid, ale to tehdy nikoho nenapadlo.

Hodne stesti pri archivovani CS souboru na opticke disky a pri zalohovani na media, kde nemas kontrolu nad tim, jaky FS pouzivaji.

A kdo rekl ze musim soubory ukladat primo na FS daneho media ? co kdyz si vytvorim prazdny soubor, v nem vytvorim napr ext4 filesystem, namountuji onen soubor do slozky a tam teprve nakopiruji ona data pak to prozenu pres gz a mrsknu na dane medium ? tak si zachovam vsechny vlastnosti ext4 a po FS na mediu je mi putna...
A nebo uplne jednoduse dana data dam do tar.gz a ten nakopiruji na cilove medium... moznosti jsou tuny

No a tuhle divnost (Kdyz si myslis ze je to divne) ma za tebe resit spravce souboru, ne FS, takze spravne by jsi mel mit CS FS a ve spravci soboru mit v nastaveni moznost "Povolit CS nazvy souboru" ... napr kdyby se win predelaval na pouziti CS FS tak bych tento option nechal vypnuty by default, a zadne BFU by nic nepoznalo.Me to treba divne neprijde, je to naprosto logicky spravne, coz bych u vypocetni techniky cekal

CS názvy jsou ale povolené. Není povolené mít dva názvy lišící se jen CS.Soubor.txt zůstává stále Soubor.txt, pouze je chápán shodný se soubor.txt i soubor.TXT.*****In NTFS, you can create unique file names, stored in the same directory, that differ only in case. For example, the following filenames can coexist in one directory on an NTFS volume:
CASE.TXT
case.txt
case.TXT NTFS supports two slightly different modes of operation that can be selected by the subsystem of the application interacting with NTFS. The first is fully case sensitive and demands that file names supplied by the application match the names stored on disk including case if the file on disk is to be selected. The second mode of operation is case preserving but not case sensitive. This means that applications can select files on the disk even if the supplied name differs in case from the name stored on the disk. Note that both modes preserve the case used to create the files. The difference in behavior noted here applies only when an application needs to locate an existing file. POSIX takes advantage of the full case sensitive mode, while MS-DOS, WOW, and Win32 subsystems use the case insensitive mode.

To ja ale vim, a cekal jsem ze s tim nejaky detailista prijde... vtip je v tom ze Windows je ted CI, to ze NTFS umi CS je vec druha, ted resime chovani aplikaci (jak by to mohlo mast BFU, BFU nepracuje s FS ale s aplikacemi ktere ten FS pouzivaji)

DNS je zase primy vstup od uzivatele, tady je CI naprosto spravne protoze CS by jen matlo uzivatele, ale uzivatel primo s FS nepracuje!

V podstatě žádné, ale nepřináší to ani nevýhody. V Linuxu je to zcela běžné a málokdo si bude pojmenuje dva soubory "Dokument" a "dokument", ale pravdou je, že "D" a "d" jsou prostě odlišné znaky a je podle mě nesmyslné se k nim tak nechovat. Otázkou je, co bude nad tím. NTFS to umí úplně stejně, ale blokuje to Windows. Možná by v OS volba "Povolit case-sensitive názvy" nebyla od věci.

No nevim, mit vse CS mi prinasi spis vice komplikaci nez vyhod. Ono napriklad email. Kdyby michal.divis@email.cz, Michal.divis@email.cz, michal.divis@Email.cz, michal.divIs@email.cz, etc. byly vzdy ruzne maily, bude to velmi chaoticke. Ano samozrejme chapu z "D" neni "d", ale...

Bavime se o FS, coz je uloziste, to jestli mailserver bude zpracovavat emaily CS nebo CI je ciste vec mailserveru ne uloziste... ale kdyz mam CS uloziste, mohu se v aplikaci svobodne rozhodnout jak budu s emaily pracovat (jestli CS nebo CI) ale kdyz mam CI uloziste tak mi proste nic nezbyva

To je pouze tvuj pohled resp tvuj zvyk.

Nejklasičtější příklad je uživatel, který si zbastlí web na svém stroji s Windows a po nasazení webu na ostrou verzi, která běží na Linuxu, zjistí, že se mu nezobrazuje spousta obrázků, které mu jeho pracovní verze ukazuje.

Ještě chybí deduplikace. Ale to je spíš problém na NASu než na workstation.

K čomu?
No napríklad k tomu, že ak ti notebook ukradnú, aby sa zlodej nedostal k tvojim dátam.

vodprejskni, blbecku!

Protože zákazníci ho chtějí. Taky využívám LUKS bez ohledu na to, jestli je to v UK/ČR wherever legální.
Až mi ukradnou ntb, tak chci řešit jenom jeden problém - kde sehnat nový. Ještě abych tak řešil, že má někdo cizí k dispozici moje data, to tak.

To je dobrá ukázka toho, jak v Apple pracuji. Chaos a šlendrián.

Svatá pravda. Měli funkci v systému nechat, i když ještě nebyly vyřešeny problémy, které způsobovala neoriginálnímu hardwaru. Ať si to uživatelé pěkně vyžerou.

Takže mají psát o čem? Nové španělské odrůdě meruněk, líp odolné proti jarnímu mrazu?

Zbytek IT světa?
On NTFS pochází ze stejné doby a ze stejného souborového systému HFS a stejně tak jako současný HFS+ nerozeznává velikost písmen ve jménech souborů, takže MS má stejné máslo na hlavě jako Apple.

Nemá máslo na hlavě. Minimálně ne kvůli Case Sensitive FS. HFS+ je case sensitive, jen je v základu nastaven, aby sice uchovával veliksot písmen, ale nerozlišoval je. Když však někdo rozlišování písmen chce, může, takže soubor Ahoj.txt bude jiný jako ahoj.txt.

Názor byl 1× upraven, naposled 17. 06. 2016 17:25

Mám pocit, že to má být až za rok. Takže Sierra bude mít pořád HFS+. A rok a půl je dost času na to, aby Adobe zapracovalo na změnách.

Adobe? A jenom rok a půl? :)

To je sice fakt, ale aspoň nemůžou říct, že na to čas neměli

Vzhledem k počtu minusů: to si fakt všichni myslíte, že Adobe upraví CS6 a nižší pro nový FS na macOS. O edici výpalného CC mi nešlo!

Tak ono určitě půjde case sensitivity vypnout, toho bych se nebál. Jen si nejsem jistý, jak to chcou udělat s tím defaultem, protože spousta aplikací CS HFS+ nepřežije. Sice jsou to prasácky napsané aplikace (každý v týmu SI tO PíšE JAK ChCE), ale je jich dost a jsou často rozšířené. Možná ale Apple bude mít nějaký příznak pro aplikaci, které mají podporu, a ostatním to bude podstrkávat s CS vypnutým...

No, obvykle není - aspoň v posledních verzích OSX... A ani implementace Samby se rychlostí nepřibližuje Windows, bohužel (mám na mysli hlavně načítání větších složek, které Win načtou prakticky hned, zatímco OSX to zabere klidně 5-10s).

To neni problem Samby ale neoptimalizovaneho Finderu. Ten nacita cely listing a metadata a az pak vykresluje.

Myslim to tak, ze je to rychlejsi nez samba a vzhledem k tomu ze jiny vyber v podstate neni... :)