Windows 10 EULA - som zhrozeny

[ByCzech]

Chápu, že ve Windows je problém s detekcí typu souboru. Ale my Windows nemáme a proto s detekcí typu souboru dle jeho obsahu nemáme ani i vámi popsaných typů. Funguje to velmi spolehlivě a transparentně. Stačí např. ověřit tak, že souborům odmažete přípony. Rozumné DE vám ve správci souborů ukáže správné ikony dle typu souborů, který zjistil z jeho hlaviček.
Lituju váš těžký život s Windows, když máte pořád takové problémy, ale neaplikujte to na OS, které používáme my, protože se s tímto chováním nesetkáváme, jen se tím ztrapňujete.

No, tak toto je opravdu výstižná essence programátorsko-patlalského hovadství.

Asi mi uchází pointa. Co je essence programátorsko-patlalského hovadství podle vás? To že Windows dle Laela neumí něco, co je jinde úplně běžné a fukční?

[Reklama]

[Lael.Ophir]

Pokud je šifrování souborů závislé na konkrétních FS, je to big fail. Dál o tom netřeba diskutovat. Mrkněte na jiné implementace téhož, ale ne od MS, zjistíte, že to přežije jakékoli kopírování mezi FS, přenosy po síti, balení do archívů, posílání emailem ap. Tomu se říká robustnost. A nepotřebuje to kvůli toho hrabat do specifikací FS a měnit je druhým pod rukama...

Pokud to jestli vám volání open() a read() vrátí obsah souboru přímo, nebo ho po cestě dešifruje, závisí na obsahu souboru a nikoliv na metadatech, tak je to největší možný fail. Pokud tohle nevidíte, tak máte celkem zásadní problém.

[Lael.Ophir]

Chápu, že ve Windows je problém s detekcí typu souboru. Ale my Windows nemáme a proto s detekcí typu souboru dle jeho obsahu nemáme ani i vámi popsaných typů. Funguje to velmi spolehlivě a transparentně. Stačí např. ověřit tak, že souborům odmažete přípony. Rozumné DE vám ve správci souborů ukáže správné ikony dle typu souborů, který zjistil z jeho hlaviček.
...

No, tak toto je opravdu výstižná essence programátorsko-patlalského hovadství.

Naprostý souhlas.

[Lael.Ophir]

Odpojený FS má mít žurnál zpracovaný do konce. Nekonzistentní FS tady neuvažujeme. Poškozený či nekonzistentní FS je potenciální problém pro data vždy. My jsme se tu bavili o FS, který chyby nevykazuje. Tak si zas nevymýšlejte krávoviny.

My se bavíme o FS, který je zapsaný v rozporu se specifikací podle které ho měli autoři psát. Jestli nevidíte že je to velmi podobná situace, tak je problém na vašem přijímači.

[Kritikek]

Nevim, co resite. tak to nepouzivejte, nebo to spis pouzivejte ale se skriptem, kterej bude preposilat veci z one drive tam a zpatky, aby si zaplnili servery bakastem. 

[Reklama]

[ByCzech]

Chápu, že ve Windows je problém s detekcí typu souboru. Ale my Windows nemáme a proto s detekcí typu souboru dle jeho obsahu nemáme ani i vámi popsaných typů. Funguje to velmi spolehlivě a transparentně. Stačí např. ověřit tak, že souborům odmažete přípony. Rozumné DE vám ve správci souborů ukáže správné ikony dle typu souborů, který zjistil z jeho hlaviček.
Lituju váš těžký život s Windows, když máte pořád takové problémy, ale neaplikujte to na OS, které používáme my, protože se s tímto chováním nesetkáváme, jen se tím ztrapňujete.

Podle všeho 1. nechápete rozdíl mezi metadaty a obsahem souboru, 2. nechápete že obsah souboru je čistě věcí aplikace a může obsahovat cokoliv, včetně věcí které lze zaměnit s hlavičkou, 3. nechápete že když shell funguje podle obsahu souboru a nikoliv metadat tak je to špatně, ale když to dělá FS, tak je to katastrofálně špatně. Za odměnu si můžete změnit první tři byty nějakého executable na %PDF, a koukat že vám ho shell detekuje jako soubor typu PDF. Případně si první dva byty nastavte na 1F 9D nebo 1F A0, a automaticky soubor dekomprimujte, protože to jasně musí být TAR, a rozhodně to nemůže být nic jiného

Lidi, je možné, aby to vážně nechápal? Lolíku, změň ve Windows libovolný EXE tak, že aniž bys HRABAL do OBSAHU souboru, jen přepíšeš jeho název tak, že místo .exe na konci bude mít .pdf. Windowsy si budou myslet, že to je PDF a posílat to do čtečky PDF! Opravdu bezva.

Váš popis opět vychází z něčeho, co neexistuje. Takhle to opravdu v Linuxu nefunguje. Ale už chápu, proč si myslíte, že detekce typu souboru přes jeho obsah nemůže být spolehlivá, když si myslíte, že to funguje tak jak jste to (debilně) popsal. Oni to takhle zkoušeli implementovat ve Windows, co? To by nám pak v Linuxu nefungovalo rozlišení mezi ZIP, JAR, libovolným ODF souborem, DOCX ap., že?! Ale věřte, že to funguje. Nástroje v Linuxu to umí rozlišit (a nápověda, bez ohledu na FS na kterém se ty soubory nachází, takže ani FS nic nedělá jak naznačujete). Prostě jste v tom úplně mimo a jen ukazujete, že o tom víte kulové, ale o to zaníceněji se to snažíte očernit.

PS: Nějak mi nedochází, proč bych měl přepisovat hlavičku ELF souboru za hlavičku PDF. Chápu, že tohle dělá ta chybná implementace EFS ve Windows 10, že mění hlavičku souboru za hlavičku EFS, ale nám se to v Linuxu nestává a nechápu proč máte potřebu navádět nás k destrukčním akcím ručně. Ucházím mi zcela smysl.

PPS: Vy musíte mít úplně nesmrtelnou hlavu... Kde nic není ani smrt nebere

[Lael.Ophir]

A jak se tam ty jedničky dostaly, když specifikace podle vás říká, že se mají nastavit na nulu? To implikuje (v dané verzi implementace), že jiná hodnota je chyba a je třeba to opravit. Pár stránek dál v diskuzi jste se za to bil jako lev, že se tam jedničky ve stávající implementaci nemají co objevovat a když je tam někdo zapíše, je to špatně. Takže vynulováním jen opravuji chybný stav. Opět jste se chytil do pasti. Legrace je, že jste si ji sám na sebe nachystal .

Ty bity jsou jasně popsané jako rezervované, s tím že podle dané verze specifikace na ně nemáte sahat. Jen idiot je vynuluje, aby se pak divil, že zase něco nakopnul. BTW vaše snaha hájit chybu implementace u Sound Devices začíná působit, jako byste ten jejich FAT32 driver dojebal - chci říci napsal - vy

Metadata FS nebo metadata struktury souboru? Plácáte to dohromady a neumíte to rozlišit. Opravdu by jste se neměl pouštět do větších akcí, protože tomu vůbec nerozumíte a jen se víc a víc prozrazujete, jak krátkozrace a plytce uvažujete. Sypte si popel především na svou hlavu. :-P

http://forum.root.cz/index.php?topic=11611.msg140756#msg140756

Přečíst to umí, o tom žádná. Ale neumí ani přenést relevatní data z místa na místo, bez poškození uživatelova obsahu. Takže FAIL. To se mi s jinými implementacemi šifrování nestalo. Ani při přenášení mezi systémy, ani při přenášení mezi FS, ani při přenášení mezi PC po síti, ani při přenášení v archivech ap. A už vůbec se mi nestalo, aby mi šifrovací implementace ničila jiná data. EPIC FAIL

Soubory zapsané bez nové funkcionality samozřejmě umí starší implementace FAT32 přečíst a je možné je zkopírovat. To že stará verze FAT32 neumí features nové verze je jaksi pochopitelné.

[ByCzech]

Pokud je šifrování souborů závislé na konkrétních FS, je to big fail. Dál o tom netřeba diskutovat. Mrkněte na jiné implementace téhož, ale ne od MS, zjistíte, že to přežije jakékoli kopírování mezi FS, přenosy po síti, balení do archívů, posílání emailem ap. Tomu se říká robustnost. A nepotřebuje to kvůli toho hrabat do specifikací FS a měnit je druhým pod rukama...

Pokud to jestli vám volání open() a read() vrátí obsah souboru přímo, nebo ho po cestě dešifruje, závisí na obsahu souboru a nikoliv na metadatech, tak je to největší možný fail. Pokud tohle nevidíte, tak máte celkem zásadní problém.

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.
Nějaký argument, proč je to fail, kromě toho, že to funguje vždy a je to narozdíl od implementace EFS od MS robustní a nemůže se to v mnoha případech pokazit a odstřihnout to uživatele od jeho dat?

[ByCzech]

Odpojený FS má mít žurnál zpracovaný do konce. Nekonzistentní FS tady neuvažujeme. Poškozený či nekonzistentní FS je potenciální problém pro data vždy. My jsme se tu bavili o FS, který chyby nevykazuje. Tak si zas nevymýšlejte krávoviny.

My se bavíme o FS, který je zapsaný v rozporu se specifikací podle které ho měli autoři psát. Jestli nevidíte že je to velmi podobná situace, tak je problém na vašem přijímači.

Ano a proto by ho utilita na opravu FS měla dát do stavu, kdy tam budou zmiňované bity v nule... A jéje, ono to odstřihlo uživatele od jeho dat.

Jak někdo může obhajovat takové patlalství mi hlava nebere. No asi proto, že vám to za ty prachy co za to dostanete stojí

[ByCzech]

A jak se tam ty jedničky dostaly, když specifikace podle vás říká, že se mají nastavit na nulu? To implikuje (v dané verzi implementace), že jiná hodnota je chyba a je třeba to opravit. Pár stránek dál v diskuzi jste se za to bil jako lev, že se tam jedničky ve stávající implementaci nemají co objevovat a když je tam někdo zapíše, je to špatně. Takže vynulováním jen opravuji chybný stav. Opět jste se chytil do pasti. Legrace je, že jste si ji sám na sebe nachystal .

Ty bity jsou jasně popsané jako rezervované, s tím že podle dané verze specifikace na ně nemáte sahat. Jen idiot je vynuluje, aby se pak divil, že zase něco nakopnul. BTW vaše snaha hájit chybu implementace u Sound Devices začíná působit, jako byste ten jejich FAT32 driver dojebal - chci říci napsal - vy

Metadata FS nebo metadata struktury souboru? Plácáte to dohromady a neumíte to rozlišit. Opravdu by jste se neměl pouštět do větších akcí, protože tomu vůbec nerozumíte a jen se víc a víc prozrazujete, jak krátkozrace a plytce uvažujete. Sypte si popel především na svou hlavu. :-P

http://forum.root.cz/index.php?topic=11611.msg140756#msg140756

Přečíst to umí, o tom žádná. Ale neumí ani přenést relevatní data z místa na místo, bez poškození uživatelova obsahu. Takže FAIL. To se mi s jinými implementacemi šifrování nestalo. Ani při přenášení mezi systémy, ani při přenášení mezi FS, ani při přenášení mezi PC po síti, ani při přenášení v archivech ap. A už vůbec se mi nestalo, aby mi šifrovací implementace ničila jiná data. EPIC FAIL

Soubory zapsané bez nové funkcionality samozřejmě umí starší implementace FAT32 přečíst a je možné je zkopírovat. To že stará verze FAT32 neumí features nové verze je jaksi pochopitelné.

Asi jste i přes několik příspěvků na toto téma přehlédl část toho co se stane. Přijdete o svá data, protože pak už se k obsahu šifrovaného souboru nedostanete ani ve W10. Což je big fail a uživatel z toho mít radost nebude.

[Lael.Ophir]

Lidi, je možné, aby to vážně nechápal? Lolíku, změň ve Windows libovolný EXE tak, že aniž bys HRABAL do OBSAHU souboru, jen přepíšeš jeho název tak, že místo .exe na konci bude mít .pdf. Windowsy si budou myslet, že to je PDF a posílat to do čtečky PDF! Opravdu bezva.

Pokud soubor označíte jako PDF, shell s ním zachází jako s PDF. Od toho tam ta přípona filename je, víme?

Váš popis opět vychází z něčeho, co neexistuje. Takhle to opravdu v Linuxu nefunguje. Ale už chápu, proč si myslíte, že detekce typu souboru přes jeho obsah nemůže být spolehlivá, když si myslíte, že to funguje tak jak jste to (debilně) popsal. Oni to takhle zkoušeli implementovat ve Windows, co? To by nám pak v Linuxu nefungovalo rozlišení mezi ZIP, JAR, libovolným ODF souborem, DOCX ap., že?! Ale věřte, že to funguje. Nástroje v Linuxu to umí rozlišit (a nápověda, bez ohledu na FS na kterém se ty soubory nachází, takže ani FS nic nedělá jak naznačujete). Prostě jste v tom úplně mimo a jen ukazujete, že o tom víte kulové, ale o to zaníceněji se to snažíte očernit.

Aha. A jak to tedy funguje? Pokud jsem si všiml, tak máte soubor /usr/share/misc/magic, který obsahuje více-méně seznam offsetů, bytů které se tam hledají, a podle toho určuje typ souboru. Což je samozřejmě nespolehlivé, protože (a opakuji to nevím po kolikáté už) obsah souboru je čistě věcí aplikace a může obsahovat cokoliv. Soubor mého textového editoru nebo souboru mého receptáře psího žrádla klidně může mít stejnou hlavičku jako soubor PDF, ZIP, může začínat signaturou EFS, nebo obsahovat cokoliv jiného. Ještě pořád vám nedošlo, že tenhle aspekt v principu vylučuje spolehlivou detekci typu souboru v jeho obsahu, a že to je primární důvod proč se na to používají metadata, konkrétně filename extension?

PS: Nějak mi nedochází, proč bych měl přepisovat hlavičku ELF souboru za hlavičku PDF. Chápu, že tohle dělá ta chybná implementace EFS ve Windows 10, že mění hlavičku souboru za hlavičku EFS, ale nám se to v Linuxu nestává a nechápu proč máte potřebu navádět nás k destrukčním akcím ručně. Ucházím mi zcela smysl.

Protože je to ukázka souboru který má stejnou hlavičku jako PDF, ale obsahuje něco úplně jiného. Soubor se stejnou hlavičkou jakou má PDF můžete vytvořit klidně v Notepadu. A ano, pokud bude záviset dekomprese souboru při čtení jeho obsahu na jeho obsahu, tak to nutně vede k možnosti, že začnete dekomprimovat něco co komprimované vůbec není. Chápeme se?

PPS: Vy musíte mít úplně nesmrtelnou hlavu... Kde nic není ani smrt nebere

No to že byste chtěl funkcionalitu volání read() vázat na obsah souboru mi fakt hlava nebere. Takovou blbost by totiž jeden pohledal. Podle vás je to ale ideální implementace. OMG :/

[Makovec]

Laele - tohle nemá smysl. Je to prostě level pro který nemají pojmový aparát a úroveň abstrakce: škoda, protože ve skutečnosti nejsou hloupí, spíš naopak.

Myslím že už neni co dodat. Třeba jim to jednou dojde až budou mít víc zkušeností a míň testosteronu :-)

Co to nechat prostě být a propadnout za horizont událostí? I s ohledem na důstojnost všech zúčastněných…

[Lael.Ophir]

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.

[Lael.Ophir]

Asi jste i přes několik příspěvků na toto téma přehlédl část toho co se stane. Přijdete o svá data, protože pak už se k obsahu šifrovaného souboru nedostanete ani ve W10. Což je big fail a uživatel z toho mít radost nebude.

Asi jste přehlédl, že pokud jde o soubory které nevyužívají funkcionalitu novější verze FAT32, tak všechno funguje jak má. A to že starší FS neumí to co novější je jaksi rozdíl mezi nimi.

[ByCzech]

Lidi, je možné, aby to vážně nechápal? Lolíku, změň ve Windows libovolný EXE tak, že aniž bys HRABAL do OBSAHU souboru, jen přepíšeš jeho název tak, že místo .exe na konci bude mít .pdf. Windowsy si budou myslet, že to je PDF a posílat to do čtečky PDF! Opravdu bezva.

Pokud soubor označíte jako PDF, shell s ním zachází jako s PDF. Od toho tam ta přípona filename je, víme?

Ale obsah souboru přece není PDF! Vám to vážně nedochází. A taky vám uchází, že Linux umí oboje. No neva. Linux neznáte, chápu a jako většina uživatelů chybné chování Windows považujete za "normální". Nic nového pod sluncem.

Váš popis opět vychází z něčeho, co neexistuje. Takhle to opravdu v Linuxu nefunguje. Ale už chápu, proč si myslíte, že detekce typu souboru přes jeho obsah nemůže být spolehlivá, když si myslíte, že to funguje tak jak jste to (debilně) popsal. Oni to takhle zkoušeli implementovat ve Windows, co? To by nám pak v Linuxu nefungovalo rozlišení mezi ZIP, JAR, libovolným ODF souborem, DOCX ap., že?! Ale věřte, že to funguje. Nástroje v Linuxu to umí rozlišit (a nápověda, bez ohledu na FS na kterém se ty soubory nachází, takže ani FS nic nedělá jak naznačujete). Prostě jste v tom úplně mimo a jen ukazujete, že o tom víte kulové, ale o to zaníceněji se to snažíte očernit.

Aha. A jak to tedy funguje? Pokud jsem si všiml, tak máte soubor /usr/share/misc/magic, který obsahuje více-méně seznam offsetů, bytů které se tam hledají, a podle toho určuje typ souboru. Což je samozřejmě nespolehlivé, protože (a opakuji to nevím po kolikáté už) obsah souboru je čistě věcí aplikace a může obsahovat cokoliv. Soubor mého textového editoru nebo souboru mého receptáře psího žrádla klidně může mít stejnou hlavičku jako soubor PDF, ZIP, může začínat signaturou EFS, nebo obsahovat cokoliv jiného. Ještě pořád vám nedošlo, že tenhle aspekt v principu vylučuje spolehlivou detekci typu souboru v jeho obsahu, a že to je primární důvod proč se na to používají metadata, konkrétně filename extension?

Dám vám radu. Stáhněte si zdrojáky a koukněte se. U FOSS není problém se ke zdrojákům dostat. Nemusíte nic podepisovat, nemusíte nic platit. Paráda, co?

PS: Nějak mi nedochází, proč bych měl přepisovat hlavičku ELF souboru za hlavičku PDF. Chápu, že tohle dělá ta chybná implementace EFS ve Windows 10, že mění hlavičku souboru za hlavičku EFS, ale nám se to v Linuxu nestává a nechápu proč máte potřebu navádět nás k destrukčním akcím ručně. Ucházím mi zcela smysl.

Protože je to ukázka souboru který má stejnou hlavičku jako PDF, ale obsahuje něco úplně jiného. Soubor se stejnou hlavičkou jakou má PDF můžete vytvořit klidně v Notepadu. A ano, pokud bude záviset dekomprese souboru při čtení jeho obsahu na jeho obsahu, tak to nutně vede k možnosti, že začnete dekomprimovat něco co komprimované vůbec není. Chápeme se?

Chápu jen to, že změnite obsah souboru a pak se divíte, proč vám spustitelný soubor už nefachčí? To samé se stane i ve Windows. Kde je teda pointa?

PPS: Vy musíte mít úplně nesmrtelnou hlavu... Kde nic není ani smrt nebere

No to že byste chtěl funkcionalitu volání read() vázat na obsah souboru mi fakt hlava nebere. Takovou blbost by totiž jeden pohledal. Podle vás je to ale ideální implementace. OMG :/

Ne vy to raději navážete na nějaké bity na konkrétním FS a když tam budou, tak ještě uděláte write() do obsahu souboru a podle vás to bude dobře. To už vážně není možné, co jste schopný vymyslet