Windows 11 budou nově moci formátovat FAT32 větší než 32 GB

Nikdy jsem nepochopil, proč to bylo v těch woknech takhle dementně omezený. I praštěný Windows 9x uměly větší než 32GB FAT32. A pak se někdo v MS blbě vyspal.

V to dobe si jeste MS myslel, ze ridi IT svet tak prisel s exFAT. Lepsi FS, bezpochyby, jenze MS to zabil patenty, ktere neuvolnil. A trhu se do toho moc nechtelo, specilne kdyz se u levne spotrebni elektroniky pocita kazdy cent nakladu.

To pocitani nakladu neni vzdycky tak jednoznacne. Podivej se treba na HDMI vs DP: i kdyz je HDMI zatizeno licencnimi poplatky, presto je (kdyz pocitame i spotrebni elektroniku) mnohem rozsirenejsi, nez DP.

Treba TV s DisplayPortem asi nenajdes, i kdyz tomu principielne nic nebrani, a DP ma nad HDMI nekolik vyhod. U projektoru ma DP snad 10%, vic ne (alespon ze se uz nake najdou). U zvuku (surround-systemy) DP nema nic. Atd, atd. Jiste, HDMI melo "naskok" uz pri svem vzniku, ale DP je tady taky jiz ~15 let, a krom pocitacu se vlastne nijak neprosadilo. Na druhe strane, HDMI u pocitacu a konzoli preziva prave kvuli moznosti pripojeni na TV...

Nebolo to opacne? DP kable boli vzdy vyrazne drahsie.

Ano, patentem je zatížený DP, na druhou stranu je lepší a bytelnější jak HDMI.

Ta penetrace je nicnerikajici valici se snehova koule - specifikum urcite produktove kategorie.

Napr. 100% serveru ma analogovy VGA port na BMC, ale za poslednich 10 let jsem nevidel zadne echt analogove zobrazovadlo, a i LCD monitory to uz zacinaji vypoustet.

Skutečné servery samozřejmě žádné grafické výstupy nemají. To, co má nějaké grafické výstupy je jen převlečené PC. Snad se s Oxide Computer a podobnými zase rychle vrátíme do stavu, kdy je možné plně ovládat servery pomocí příkazové řádky ve všech případech, či pomocí API a obojí přes síť.

Grafika do serveru patří jen jako akcelerátor, ne předpoklad pro schopnost jej plně ovládat.

HDMI je jen lehce oprčášené DVI, používá stejné kódování a stejné IO.
Implementačně je velmi jednoduché, a tím i levné (min. do FULL HD 60Hz, tam stačí něco jako 130nm proces).
DP je mnohem, řádově složijejší a potřebuje daleko více prostoru na křemíku, lepší technologii, zároveň již hotových čipů s ním je výrazně méně, a tak se do produktů hůř integruje.

Od dob HDMI2 to je uz trocha jine - je tam pridany scrambling, a pak u 2.1 to pouziva 16b/18b a volitelnou kompresi.

DP je hlavně paketovaný přenos, je to mnohem modernější protokol. Apple to pochopil rychle, nakonec se DP rozšíří i díky alternativním módům a USB typu C.

DP umí mimochodem přepnout a vysílat HDMI signály, takže lze z DP na HDMI použít pasivní redukci. Prý se tím dají obejít různé implementační bugy kolem HDMI např. na dokovacích stanicích.

Nevim o tom ze by DP mel nejakej ekvivalent k funkcim jako je CEC nebo ARC.

V DP mel byt kanal ekvivalentni k USB2, ale zadny produkt to neimplementoval. A pak pozdeji uz prislo TypeC, ktery implementuje prave USB + neco navic, treba DP ALT mode.

Jinak CEC ma jakysi ekvivalent v DDC/CI, komunikace je mozna obojim smerem. Typicky se to vyuzivalo na sdeleni orientace monitoru kdyz byl preklapeci, nebo na rizeni podsviceni. Vzniklo to davno pred CEC, coz se samozrejme u HDMI nelibilo a vytvorili si onen placenej CEC.

Priamo od autora: https://www.youtube.com/watch?v=bikbJPI-7Kg

12 min video? Nešlo by to shrnout do pár vět?

Šlo. Borec se prostě rozhodl, že 32GiB bude dostatečný po dobu životnosti Windows NT 4.0. Navíc - mělo se jednat o dočasné řešení (na dobu Windows NT 4.0), než někdo změní celé UI toho formátovacího bazmeku. Jenže to se od té doby nestalo, ten krám je pořád stejný i v dnešních Windows 11. Ostatně Windows 11 nejspíš dodnes umí naformátovat 5,25" disketu na 1,2 MB (nezkoušel jsem to, ale můžu, potřebným hardwarem vybaven jsem a možná najdu i desku s FDD řadičem, která dovolí nastavit v BIOSu i 5,25" mechaniku a utáhne po obejití HW limitů Windows 11).
Zkrátka udělal špatné rozhodnutí, které od té doby nikdo nezměnil.

V tom videu mi ale není jasné to tvrzení, že maximální počet clusterů ve FAT32 je 4M (4:55).

Aha, to je dobrý, přidal jsem to. Díky

Asi hezký... - ale YT mi odmítá pustit video, dokud se nepřihlásím a dokud si neověří můj původ. Řekl bych, že (alespoň pro mne) éra odkazovaných videí právě definitivně (?) skončila. ;o(

Nevim co s tim delas. Na odkaz jsem kliknul pravym - open in new private window, normalne se to nacte, vyskoci nejake html okenko a dam Reject all, a presto to video hraje.

Začnu stejně: kliknu pravým, otevřu v privátním okně... - a místo videa mám jen černý obdélník s upozorněním: Přihlašte se a potvrďte, že nejste robot. ;o(
V podstatě totéž se stane, pokud se pokusím stáhnout to video pomocí yt-dlp (aktuálního).

To je nejaky novy trend mrkvosoftu, opravovat historicky software? Posledne to bylo neco s poznamkovym blokem, ted zas moralne i technicky zastarale FAT32...

(Jasne, semtam nekdo poznamkovy blok pouzije, ale kdyz jde fakt o neco, tak vetsina sahne po necem lepsim. A ano, i fat32 jeste najdem vsude mozne kolem, ale opet kdyz to jde uz se to nepouzije.)

Zrovna v případě FAT32 to ovšem narozdíl od Poznámkového bloku leckdy naprosto jinak nejde. A ostatně i co se Poznámkového bloku týká to mnohdy není moc praktické řešit jinak.

FAT32 v některém aplikacích nemá konkurenci. Viz. jen perfektní přenositelnos­t....na karty / USB flash nic lepšího není.

No ano, jak pisu - kdyz to jde uz se to nepouzije.

Rozhlednete se kolem, bezne BFU uz ani nema flashky. Staci jim wifi, data, cloud. Driv jsme neco vyfotili, kartou to prenesl z fotaku do pocitace, flashkou predal kamaradum. Dnes se vyfoti mobilem a ten to rovnou nahraje do cloudu.

Kdy naposled jste potreboval nahrat extremne velky soubor na flashku? Ja naposled kdyz jsem kopiroval nejaky film a televize nemela ethernet/wifi.

Za mě jsem na to narazil u Truecrypt (dneska Veracrypt) kontejnerů, kdy třeba na 32GB flashce chcete nechat polovinu nešifrovanou, a na druhou polovinu vypadá nejjednodušší vytvořit soubor (protože je s ním nejjednodušší práce) s šifrovaným kontejnerem. Tak to je na FAT32 problém, 4GB velikost kontejneru je dost limitující, a nelze dělat kontejner na více částí (teda dřív to nešlo).

Já flash disky používám úplně běžně. Třeba duální usb C/A na přenos a uložení dat ve spolupráci s mobilem, tabletem - tam používám terové flash disky. Dále je používám při používání kláves, zejména staršího Korg Kronos a nového Korg Pa5X. Kronos sice obsahuje i FTP server, ale třeba zvukové banky nejde instalovat z jeho interního disku. V práci zase vyhrazené usb flash disky používám pro přenos dat z různých řídících systémů, které nesmí být připojeny k ethernetu.

1) FAT32 hodně ořezávali údajně na podnět ochránců autorských práv. Například pro velikost souborů. Jenže svobodný XviD jim to pokazil.
2) FAT32 nemá žurnálování (režie systému je zanedbatelná). Hodí se na nenáročné ukládání na USB-flash.
3) S podivem u smart TV ještě letos roku 2024 stále málokdy jiný file system než FAT32.

1) Velikost souborů je daná 32bitovým číslem v metadatech, což se vleče už od počátků DOSu. Od té doby se to nikomu nechtělo předělávat. Pro profíky bylo NTFS. DVD na FAT32 jde zkopírovat úplně v pohodě, protože obsahuje soubory dělené po 1 GB.
2) Právě na ty flashky by podle mě žurnálování metadat být mělo. U odpojitelných zařízení je zvýšené riziko, že činnost FS bude násilně přerušena. S žurnálováním metadat by se jen ztratila část naposledy zapsaných dat v otevřeném souboru. Bez něj se může rozbít náhodně cokoliv.

A víte, proč na nich není? Tak si to zjistěte a pak podobné nesmysly nebudete muset psát.

Těch metadat zas není tolik, aby se ta flashka nějak významně vošoupala.

Teraz bude cloveku smutno ked bude mazat Win z disku aby tam mohol nainstalovat OS.

To ze ty ho nepouzivas notepad, nezanamena ze ho nepouzivaj jini. Od te doby co zavedly taby tak tam mam rychle poznamky o ktere mi uplne nevadi kdyz o ne prijdu, ale hodej se... Takze mam asi 20 tabu poznamek k ruznym vecem, a ani je neukaldam. Stejne si je zase po restartu nacte z app data....

Lepsi nez to psat rucne nekam do bloklu vedle....

"To ze ty ho nepouzivas" - A tuhle moji cast:
"semtam nekdo poznamkovy blok pouzije"
jsi ignoroval zamerne?

Ja bych rekl, ze pocet lidi pouzivajici poznamkovy blok windows pro nejakou rozsahlejsi praci je pomerne maly. Ted bych tu asi mel dodat odkaz se statistikou pouziti notepad vs notepad++, pspad, a hromadou jinych textovych editoru, ale myslim ze doopravdy neni potreba.

Jestli se mi to nezdálo, tak malování=mspaint dostal podporu vrstev...

Copak to nešlo zformátovat pod WSL?

error: moc prace

To je ovšem zcela validní error.

Daleko snazší na to bylo použít nástroj třetí strany. Třeba mnohokrát zmíněný Rufus. Ten nemá problém naformátovat 64GB flešku na FAT32 s 16KiB clustery.

C:\Windows\system32>chkdsk D:
The type of the file system is FAT32.
Vytvoření stínové kopie určeného svazku není podporováno.

The volume is in use by another process. Chkdsk
might report errors when no corruption is present.
Volume Serial Number is 1EEB-3F64
Windows is verifying files and folders...
File and folder verification is complete.

Windows has scanned the file system and found no problems.
No further action is required.
   61 039 584 KB total disk space.
   61 039 568 KB are available.

       16 384 bytes in each allocation unit.
    3 814 974 total allocation units on disk.
    3 814 973 allocation units available on disk.

Formátovat na FAT32 disk větší než 32 GB šlo už dávno, ale pouze za pomocí speciálního programu. Třeba EaseUS Partition Master.

jj, to bylo až do toho posledního buildu W11 omezení jen té formátovacího dialogu v gui, která se zavolá z průzkumníka. Systém samotný s tím nakládá normálně.
Také jsem to obcházel a obcházím, když je to potřeba.
Krom zmíněných partition manageru, je to nejjednodušší asi s Rufusem, nebo pokud nevadí příkazová řádka, tak lze úplně v pohodě použít editor diskpart, který je součástí Windows.
Co si vzpomínám, tak už jsem to přes něj formátoval někdy v dobách Windows XP. Třeba když bylo třeba naformátovat externí disk, aby se na něj dalo následně zapsat i na standardním MacOS bez dalších 3rd party ovladačů. Nebo například pro nějaký specifický hardware (dedikovaný audio rekordér), který neuměl jiný souborový systém než FAT32.

Vodjakživa mkfs.vfat resp. mkdosfs -F 32 .

Jak jsem zmínil: formátovat FAT32 na víc jak 32 giga uměly už Windows 9x bez jakéhokoli nástroje třetí strany. Jenže pak si Dave Plummer usmyslel, že „32 GiB na FAT32 musí stačit každému“. Přitom taková blbost…

Osobně jsem *FAT* na flashkách donedávna nepoužíval vůbec.
UDF mi vždycky fungovalo výrazně líp, a jelikož je to nativní FS DVDček, je jeho podpora na všech desktopech. Teprve po skončení patentový ochrany exFAT jsem začal používat tu, protože zejména některý flashky s ní jedou klidně násobně rychleji než pod jakýmkoli jiným FS.

20. 8. 2024, 16:16 editováno autorem komentáře

UDF které verze je to správné?

S 2.50 jsem nikdy nikde problém neměl.

Nikde ani ve WinXP SP3 ?

Já to zkoušel právě teď a XPčka to připojily jen pro čtení.

FAT32 je dalsia sprostost ktora nemala vzniknut, spolu s debilnym systemom VFAT na ukladanie LFN. Ten system je umelo okrypleny na 28 bitov, skutocnych 32b pouziva az exFat.

https://wiki.osdev.org/FAT

Tak zas vznik chce asi posuzovat v nějakém kontextu doby vzniku.
NTFS řešilo zgruntu spoustu věcí mnohem líp (a to beru v potaz nejen FAT, ale i tehdejší stav ext2, FFS) a přišlo v r. 93, do pár let potom už to mělo v NT4 kompresi, ACL atp.
Akorát bylo na spousty zařízení a použití v té době příliš heavy-handed, navíc bylo NTFS úplně uzavřené a svázané s jedním OS.
FAT12/16+VFAT, resp. FAT32 byly uvedené jako implementačně jednodušší, kompatibilní přechodové varianty vhodné i pro výměnná zařízení atp. Zpětně se to může zdát jako nešťastný krok, ale u MS byla kompatibilita vždycky prioritou i když si do budoucna přidělali kouli na nohu (třeba v porovnání s relativně mnohem rychlejšími změnami u Apple).
ExFAT přišel až o víc jak dekádu později, byl také patentovaný, a neměl volnou specifikaci až do roku 2019. Což jeho rozšíření upřímně vzato také moc nepomohlo.

Navíc i přestože ExFAT řešil spousty nedostatku návrhu původní FAT, tak jsou tam pak také praktické věci, které nejsou úplně šťastné. U původního systému například spousta zařízení zapisovala FAT část paralelně dvakrát, takže při nějaké závadě povrchu, kdy byla ta první nečitelná na špatném sektoru, dalo se zkusit použít tu druhou a zvýšila se pravděpodobnost obnovy (bez pracné rekonstrukce souborů analýzou datové části). U ExFATu je sice také možnost mít dvě FATky, ale je to víceméně specifikací svázáno se subvariantou TexFAT (transakční), která se, co vím, používala jen na Windows CE. Prakticky jsem se s tím nesetkal a většinou se FAT zapisuje jen jednou.

20. 8. 2024, 00:08 editováno autorem komentáře

Zpetna kompatibilita mozna, kompatibilita jako takova ani omylem (a pokud se nahodou neco takoveho stalo, tak to bylo rychle "napraveno")

Je to hlupost aj v kontexte doby, davno existovalo napr. HPFS (1989). Spatna kompatibilita nebola ziadna pretoze to malo ine Partition ID.

Tu je zoznam toho kde sa dalo inspirovat.

Omlouvám se, ale nejspíš jste špatně pochopil můj předchozí post.

Oni v té době nedělali pokročilou náhradu FAT filesysému, to už bylo a jmenovalo se to NTFS. Btw. to HPFS z IBM OS/2 používali také, měli spolu deal, než se vyvinul Windows NT, které bylo HPFS poměrně dost inspirované. Dokonce NT 3.x mělo driver pro HPFS (a platili z toho licence IBM). NTFS byl pokročilejší filesystém než HPFS, měl žurnálování a byl připravené na postupné přidávání dalších vlastností, které přišly později (ACL, komprese, šifrování). Což byl i důvod, proč samo IBM mnohem později přidalo do OS/2 JFS, který byl původně jen v AIXu.

Ale zpátky k FAT a kompatibilitě. Jak více, tak MS vyvíjel v devadesátých letech dvě větve svých OS. První bylo NT s novým kernelem, filesystémem a spoustou věcí řešených z gruntu jinak. Tam bylo hlavní kritérium udělat věcí líp a s výhledem do budoucna. Mělo to vyšší HW nároky, zpočátku se to primárně používalo na serverech a pracovních stanicích.

Druhá vyvíjená větev systémů (95, 98, ME) byl takový schizofrenní hybrid. Protože tam byl pořád přítomen režim DOSu, v kterém byl dosupný real-mode a přímý přístup na hardware. Důvod byl ten, že za minulých 15 let se nasbíraly desítky tisíc aplikací a her, a dost z nich nechodilo dobře v režimu nových Windows s GUI, virtuální pamětí, schedulerem. Klienti a firmy chtěly tyhle aplikace používat, byla to i pro MS priorita u téhle větve.
Když jste tedy ukončil Windows, nebo přerušil startovací process (klávesou F8, nebo direktivou v msdos.sys), tak jste byl v "normálním" DOSu (7.0 ve Win95 a 7.1 ve Win98).

Logicky tedy i použitý souborový systém musel být schopen schopen fungovat v DOSu. Takže se rozhodli upravit, to co měli - FAT.
Novou fíčuru - dlouhá jména tam přidali přes VFAT, kde má každý soubor pro adresář dva záznamy, přičemž první je s dlouhým názvem a druhý s krátkým názvem 8+3. Když implementace podporuje VFAT, tak se použije první záznam a následující se rovnou přeskočí. Pokud nepodporuje, tak první záznam ignoruje a použije se ten druhý. Díky tomu máte i soubory s dlouhými názvy zapsané třeba na disketu kompatibilní s ostatními počítači, kde není VFAT podporován.

U té změny na 32(28)bit adresování šlo zas o to, že chtěli podporovat větší disky, ale zároveň udělat jen nejmenší změny v existujícím souborovém systému, při zachování jeho relativní jednoduchosti.
Nemohly moc vzrůst paměťové nároky (v real-mode DOSu, kde má běžet i aplikace nemáte moc prostoru pro nějaké pokročilejší věci jako bitmapy, b-tree atp.). Také to samozřejmě bylo implementačně jednodušší, jak pro úpravu samotného DOSu 7.10, tak pro hromadu ostatních výrobců, kteří FAT32 také implementovali (resp. mohli jen s minimálním úsilím modifikovat jejich stávající kód pro FAT16).

Ano s odstupem 30 let to samozřejmě svádí k nějakému absolutnímu srovnávání se všemi existujícími FS té doby, ale ten kontext je opravdu potřeba.

Nedávno jsem řešil jaký FS vybrat pro přenos dat mezi Lin, Win XP a novějšími.
Vyšlo mi z toho lépe exFAT, kvůli podpoře souboru > 4GB

Akorát ve WinXP to chtělo vytáhnout ze záhrobí správný patch:
https://archive.org/details/winxp-exfat-driver
God Bless Webarchive.

a co UDF? nativně je ve všech DVD-aware systémech (takže od 98OSR2 nahoru žádný patche instalovat nemusíš), a 16EiB velikost souboru musí stačit snad úplně každýmu :-)

20. 8. 2024, 16:19 editováno autorem komentáře

Díky za tip, ten mě nenapadl a tak jsem se po něm podíval a plánuji ho vyzkoušet.

Proč pro něj nejsou běžně v Linuxu připravené utility (jako pro jiné běžné FS) a je třeba je instalovat?

V některých diskuzích hlásili problém se zapisovatelností pod WinXP, že ho tam měli připojený jen pro čtení.

Doporučovaný postup je zeroing před formátováním, trochu nepraktické.

Místy hlásili problém s dostupnou velikostí, která byla nižší, než skutečná.

Ale dám mu šanci.

UDF sice zní jako teoreticky dobrý nápad, ale pečlivě si to ozkoušejte. V praxi můžete dost narazit s implementacemi těch ovladačů v různých systémech.
Další věc je, že to bylo fakt primárně svázáno s dobovými optickými médii, nikdo to moc nerozvíjí dál, netestuje, neoptimalizuje.

Stran té kompatibility, je tam pár problémů, které už zřejmě nikdo nebude řešit.
Na Windows je například několik problémů.
- UDF nefunguje to zařízeních s nativním 4k blokem, případně s emulací standardního 512b (512e).
- Windows vyžadují mít MBR a UDF partition přes celý disk. Ostatní systémy ne, tam naopak být nesmí, aby se to automaticky připojilo. Existuje na to workaround, s fejkovou MBR na začátku disku. Celkem prasečina, která občas rozbíjí připojení i na některých zařízeních.
- progresivní zpomalování při operacích s větším množství souborů (např. kopírovat tisíce souborů z nějakého git repa). Občas totální výtuhy při souborových operacích (i když je to z normálního disku).
- na Windows XP s posledními service packy je UDF jen read-only, zápis případně jen s ovladači třetích stran (Sonic, Nero..).

Bohužel si to pamatuji ještě z období různých CD-RW, DVD RAM napříč systémy atp. Že by to bylo spolehlivé, to se úplně říct nedá, obnovoval jsem i pár poměrně kritických průšvihů.
Možná na nějaké velké soubory (jako filmy na flešku) v pohodě, případně vytvořit image a už neměnit obsah a jen z ní číst, to bude také v klidu. Na nic moc jiného bych to neřešil.

Další věc je, že třeba exFAT nebo FAT32 na relativně novějších linuxových jádrech podporuje posílání trim (online discard option, nebo přes fstrim). Pokud by to bylo třeba na externím SSD, tohle je docela zásadní fíčura. Jinak s UDF byste musel vylejt všechna data, poslat blkdiscard na trim celého zařízení a pak data vrátit.

Na zmíněné problémy se skrytou partition, případně přehled workaroundů se můžete podívat třeba sem:
https://github.com/JElchison/format-udf
Je tam shell skript pro přípravu takového divnoodílu, jinak tu skrytou partition umí rovnou udělat i mkfs.udf z udftools.

Osobně bych se na zapisovatelné UDF vykašlal. Pokud jste si už našel cestu s exFAT, nebo ještě líp s NTFS, tak obě tyhle zmíněné varianty budou podle mě za současného stavu lepší.

Tak to mám možná kliku, že jsem na žádný z těch problémů nenarazil.

Vyzkoušel jsem a ve WinXP je to ReadOnly, takže pro mé potřeby nevhodné.

Vzhledem k probíhající diskuzi o divných číslech omezeních fat32 dodávám výsek výstupu cmd "format /?" na windows 7
/A:velikost Přepíše výchozí velikost alokační jednotky. Pro
všeobecné použití se doporučuje používat výchozí
nastavení.
....
FAT32 podporuje 512, 1024, 2048, 4096, 8192,
16k, 32k, 64k, (128k, 256k pro velikost sektorů
větší než 512 bajtů).
....
Systémy souborů FAT a FAT32 obsahují
následující omezení počtu clusterů na svazku:
....
FAT: Počet clusterů <= 65526
FAT32: 65526 < Počet clusterů < 4177918
....
Příkaz Format bude ukončen, pokud zjistí, že
daná omezení nelze při zadané velikosti
clusteru dodržet.


Tez jsem resil prenos dat a jako nejlepsi reseni mi mezi win, lin, mac vysel sexfat. A je to dost skoda, protoze druhy v poradi je ntfs, ktery by byl lepsi, ale bohuzel na mac jsem nenasel free ovladac.