Ono to zas tak jednoduche neni:
Vzhledem k tomo ze autoritativni zdroje ( LaelOphir ) rikaji, ze specifikace pozaduje pri vytvareni soboru nastavit reservovane bity na 0 a pak uz je nikdy nekontrolovat zksme tuhle hypotezu:
Dejme tomu ze firma SD napise program na spojovani souboru: ten vytvori, presne podle specifikace specifikace novy soubor s obema bity nastavenymi na 0 a postupne do nej zkopiruje data ze vstupnich souboru, ktere maji tyto bity != 0. Vysledek asi nebude fungovat ale bude podle specifikace.
Tím autoritativním zdrojem nejsem já, ale specifikace FAT32, kterou jsem opakovaně linkoval.
Samozřejmě staré implementace FAT32 nemohou umět to o co byly rozšířené nové specifikace. To je omezení dopředné kompatibility. Ext2 také neumí třeba přehrávat žurnál ext3. V případě FAT32 můžete už na Windows 95 OSR2 přečíst soubory zapsané na Windows 10, samozřejmě pokud nepoužijete věci které Windows 95 OSR2 neumí (třeba to šifrování). Nicméně šifrovaný soubor uvidíte na staré implementaci FAT32 s příponou .PFILE (tady děkuji MD že na to upozornil), takže by s tím neměl být problém.
S žurnálem Ext2 vs Ext3 je to zcela nerelevantní příklad. To nijak neovlivňuje uživatelovat data. Stejně jako neovlivňuje překopírování dat z FAT (bez žurnálu) na NTFS (s žurnálem) a následné čtení (tedy pokud ta data nebyla šifrovaná novým dementním systémem). 
Problém s tím je, napsali jsme jaký. Ztrácejí se infromace, které způsobí, že stejný soubor s příponou .PFILE jednou rozšifrovat jde a po zkopírování nejde - EPIC FAIL!
A to ten tatar jeste nevi, ze pokud se ext3 primontuje v rezimu ext2 a zapise se na to, tak to nasledne neni zasadni problem, protoze tam nebudou jen prave ty zurnaly, s cimz si opravovator fs poradi. Ale rozhodne to nezmrvi data userovi.
Neblbni cece, to by nebyla M$ way, a dokonce by to i fungovalo. A dokonce to tak i funguje - teda pokud si nainstalujes non M$ appky ktery sifrujou jednotlivy soubory.
To by samozřejmě nefungovalo, protože obsah souborů je věc aplikace, může tam být cokoliv, a tedy je to nespolehlivý detekční mechanismus.
Mno dment jako ty samo nedokaze pochopit, ze kdyz mam nastroj na opravy disku, tak bit nastavenej do 1 tam, kde ma byt 0 je jaksi presne jedna z tech chyb, ktere by bylo zahodno opravit, ze.
Milý nedouku, ta specifikace zcela jasně říká, že máte na začátku nastavit bity na nulu a dál se o ně nestarat, protože jsou rezervované. Skoro ani nepřekvapí, že zrovna vy to čtete jako "tohle musí být vždy na nule". Čtete to samozřejmě úplně špatně.
Jasne, protoze M$ udela sifrovanej soubor a neumi si k nemu pridat dostatecne jednoznacnou hlavicku. Vis ty trotle, ze na hlavickach je zalozenej celej internet?
Jenže ty hlavičky jsou dané standardem, a nemohou být zaměněny s obsahem paketů, tedy uživatelskými daty. Naopak obsah souboru je zcela v režii aplikace, a mohou v něm být jakákoliv aplikační data, včetně libovolné hlavičky. Až pochopíte rozdíl mezi data a metadaty, přijďte zpátky si sypat popel na hlavu.
Kompatabilni zcela jiste neni, jak tu uz dobra duse dokazala experimentem, co na to rikas luliku? Hovno vid? Protoze ste mu prave zkurvili jeho zasifrovany data svoji nekompatabilni zmenou FS.
Stará implementace FS umí přečíst to co je zapsané bez nových features, tedy v tomto případě bez šifrování. Což je naprosto v pořádku.
Ano, imbecil tve kategorie samo nedokaze pochopit, ze aplikace vidi jen to, co ji predlozi system. Nevsim sem si, ze by si nejaka aplikace cetla sektory na disku. Stejne tak jako imbecil nedokaze pochopit, ze pomerne bezne M$ checkdisk (teky dokaze zcela spolelive zkurvit libovolna data i na disku kterej destiky nikdy nevidel) ZAPISUJE a to kupodivu tak, aby predevsim METAdata uvedl do souladu s tim, co se ocekava, a s tim, co vykalkuluje ze by tam asi tak mohlo byt. A jelikoz bit ma byt 0, tak tam taky tu 0 nastavi. (vrele doporucuju tenhle tool z widli odpreparovat predevsim, tem, kteri chteji pouziva zcela libovolne sifrovani - trebas i truecrypt).
Stejne tak trotl jako ty nedokaze pochopit, ze obsah paketu je dan hlavickou, kupodivu (jak prekvapive) se tak rozlisujou ruzny protokoly, a to dokonce na nekolika urovnich, kdy je (nejakym zazrakem) do ethernet ramce vlozej ip datagram a jeho ohsahem muze byt trebas tcp a v nem jeste muze byt vlozeno treba http a kdyz na tom prijde, v tom http muze byt klidanko dalsi tcp. A kupodivu, coz imbecil z M$ nemuze samozrejme nikda pochopit, z pohledu aplikace je to nejaky stream dat, a spousta hlavicek je ji zcela uzadeke, protoze je vzivote neuvidi, protoze ty hlevicky jsou starosti HW a OS. Zajimavy ze presne stejne se chovaji VSECHNY sifrujici kousky SW, KROME toho do M$.
Ve finale stara implementace nejen ze NIC cist neumi, maximane zobrazi jakysi binarni blob, ale se 100% jistotou data ZNICI, pri jakemkoli pokuu je kopirovat/presunovat/... coz je zcela bezna operace. A muzes tu napsat jeste klidne 100xty svy blaboly, na tom ze ses negramotnej kreten to nic nezmeni. O kdyz se obavam, ze definice kretenismu je v tomto pripade slaby kafe.
Tak ajťáci by mohli a měli vědět, že features z nové verze FS nejsou na staré verzi FS k dispozici. A když jim to nedojde, tak nejspíš následně budou schopni najít někoho, kdo nastaví dotyčný bit diskovým editorem. A když ne, tak dostanete padáka, protože jste měl důležité firemní informace pouze na přenosném médiu. Ale jinak je to moc pěkná pohádka
Jasne ty kretene, a meli se to dozvedet z neexistujici specifikace, ze?
Ne, závisí to na metadatech. Ale ne na metadatech FS. Metadata můžou být i ve struktuře souboru. Pár zpráv zpátky, jsem vám říkal, ať se to doučíte a vy se znovu ztrapníte.
Metadada v souboru jsou nutně nespolehlivá, protože každá aplikace může zapisovat do souboru cokoliv uzná za vhodné, včetně obsahu který je záměnný s metadaty. Pokud vám nedochází že je to v principu nespolehlivé, a chování volání read() se tím tedy nemůže řídit, tak prosím vylijte na základní desku svého stroje sklenici slané vody, a jiný počítač si nekupujte, protože byste mohl ublížit nejen sobě, ale kdybyste se nějakým omylem dostal k psaní kódu, tak i někomu jinému.
Ano imbecil co netusi jak funguje FS, a ze si na disk muze zapsat co chce. Zjevne neexistuje trebas zip. Divny, ze snim widle, sice blbe ale prece, umej fungovat tak, ze user vubec nemusi tusit, ze cte/zapisuje do zipu. Mno widle sice ten soubor detekujou podle pripony, coz je nahovno, protoze kdyz to nahodou neni zip, tak posilaj kravsky hlasky. Ale kupodivu, kvuli tomu nemusej kurvit userovi data. Divny co? A kupodivu i kdyz ten zip skopiruju pod DOSem, tak se nezkurvi. Divny co?
JAKEJ je rozdil mezi ZIPEM a tou sifrovaci srackou? Presne ZADNEJ. Jen tu sifrovaci sracku implementoval dement.
No, tak kamery asi nebudou sifrovat, tak je to jedno. A kdyby MS zvolil nejaky normalni zpusob znaceni sifrovanych souboru, problem by nebyl ani se zarizenimi z SD.
Jenze ono ti to zkurvi data i tak, ze vemes SDcko z telefonu, neco na nej pod widlema natlacis, a v tom telefonu si to pak trebas presunes do interni pameti a je to v <>.
Tak ja to nechci urcovat podle obsahu souboru, ale podle jeho hlavicky.
Tam může vzniknout problém akorát v tom, když se někomu podaří navrhnout strukturu (např. datových) souborů své aplikace tak, že jejich počátek (hlavička) odpovídá šifrované variantě na daném oddílu/svazku používaného souborového systému. Pak minimálně při čtení takových dat může být člověk dost překvapen, co na něj vyleze (i když ta pravděpodobnost je malá). To teoreticky vyřeší použití bitu v metadatech.
Jasne, mel by sis rozsirit pojmovy aparat a jit se podivat jak funguje zip, a klidne si vyzkousej vyrobit textak a prejmenuj ho na zip ... divny co, dmentni hlasky, ale zadna katastrofa, narozdil od tohodle. Samo, kdyby widle fungovaly jako tux, mozna by i poznaly, ze to neni zip ale textovej soubor.
682 Odpovědí
121055 Zhlédnutí