Fórum Root.cz
Hlavní témata => Windows a jiné systémy => Téma založeno: mikesznovu 20. 12. 2024, 20:27:23
-
windows rage! proč windows11 ani deset odmítají naformátovat přes diskpart oddíl disku na čtečce karet? vrací to "tato operace není podporována na vyjímatelných médiích"
Proč do háje? indové prostě řekli ne ?
postup:
select disk 2; clean; convert gpt ; create partition efi;select part 1;format fs=cokoli quick
Proč potom tedy windows umožní mazat oddíly ,disk, vyměnitelný, ale ten poslední krok ne? To je nějaký indický kanadský žert?
-
Pokud pořád platí, že Windows podporují na vyměnitelných médiích jen jeden a to datový oddíl, tak asi nemá smysl, aby na nich diskpart uměl vytvářet EFI.
Nech si ty poznámky o Indech a ptej se normálně. Proč tenhle debil ještě nedostal ban?
-
Tak kdyz to neumi windows, tak si tam dej nejakou aplikaci ne? :D taky v linuxu nepouzivame "cat >/dev/sda" na vytvoreni MBR/GPT, ale uzijeme priinstalovanych pohodlnych toolu typu fdisk/gdisk ,)
-
Ze stejného důvodu se mohu ptát, proč nedostali ban ti, co ostatní diskutující nazývají debily apod.
Nicméně k věci:
Windows jsou v tomhle hloupý, ale dají se obelstít.
Postup: Diskpart:
sel dis <n>
clean
convert gpt
crea par efi size=512
exit
Tím práce diskpartu končí, protože dál neumí (ano, protože „Indové se tak rozhodli“). Neumí ani ten svazek mountnout jako písmeno. Ale lze pokračovat v příkazovém řádku:
mountvol /LNa konci je vypsán seznam viditelných svazků. Ten náš bude pravděpodobně poslední, ale aby měl člověk jistotu, je nanejvýš vhodné tento příkaz pustit ve vedlejším okně v momentě, kdy je na flešce uděláno clean (případně po convert gpt). To tam ještě ten svazek není. Až po crea par efi … se vylistuje další svazek a ten co přibyde, ten to je. A uděláme (celý ten řetězec za S: nahradit příslušným svazkem - přičemž S: je mountpoint - písmeno, lze měnit dle libosti, tedy volných písmen):
mountvol S: \\?\Volume{6af8d72e-af0f-4698-a207-9405f70fda2a}\
format S: /FS:FAT32 /Q (a odentrovat po výzvě typu Insert new disk for drive S: and press ENTER when ready...)
Vtip je v tom, že ani poté diskpart přes lis vol ten svazek S: neuvidí. Prostě indický produkt. Ale funguje to.
Po ukončení práce se svazkem je dobré ho odmountovat:
mountvol S: /D
-
Teda, smekám před vaší sbírkou rovnáků !
-
Nejde o sbírku. Problém mě zaujal a zajímalo mě, zda má řešení. Tak jsem ho našel :-).
-
Teda, smekám před vaší sbírkou rovnáků !
To není sbírka rovnáků. Každý produkt má svoji specifikaci, svoje schopnosti. Pokud si do hlavy posadíte myšlenku, že by ten produkt (Windows) měl umět něco jiného, není to problém Windows, ale Vaší představy. Krom toho, je poměrně známo, že v GUI Windows umí jen menší část svých funkcí, což ostatně platí i o linuxu. Dokonce by se dalo říct, aniž byste učinil nějakou chybu, že linux umí z GUI ještě daleko méně operací pro správu, než windows.
Někdy mi přijde, že ty komentáře nemají hlavu a patu. Dokud se vše v linuxu ovládalo přes CLI, bylo to dáváno za přednost. Nyní, kdy v CLI Windows uděláte ještě víc, tak se zase začíná kritizovat, co vše nejde naklikat :). To je postavené na hlavu.
-
Ak ono dnes uz lidi nectou a ani se bohuzel netvori referencni manualy, jako v dobe "bez internetu". To byla knizka cenny zdroj informaci o tom, co vse lze v systemu udelat ... a zadna knowledge base nebo strojove generovana a prekladana omackoidni online dokumentace to nenahradi. Pak lidi nemaj vubec poneti co je mozne, a co jak funguje. Protoze ani uz ty kurzy nejsou takove jako to byvavalo.. a na skole se tohlecto taky neuci. Me prijde ze cely WIN svet presel na styl pokus-omyl.. a nikdo nic nevi. Zatimco u Linuxu to fungovat muze, protoze existuje komunita, u komercne pojate a tezke konkurecni platformy kde si spravci strezi sve knowhow, to fungovat samozrejme nemuze.
-
Me prijde ze cely WIN svet presel na styl pokus-omyl.. a nikdo nic nevi. Zatimco u Linuxu to fungovat muze, protoze existuje komunita, u komercne pojate a tezke konkurecni platformy kde si spravci strezi sve knowhow, to fungovat samozrejme nemuze.
Tento směr laicizace je patrný i v linuxu. Lidé, kterým bych nesvěřil ani naklikání DNS ve windows managementu, dnes podle návodů "perlí" v linuxu. O tom, jaké jakosti jsou ty návody, se snad ani rozepisovat nemusíme, dobrých 80 % rad, možná i víc, je balast na vyhození do koše.
Nechci vyvolávat flamewar, ale referenční příručky pro instrumentaci windows jsou dnes v lepším stavu, než v linuxu, a k tomu navíc ještě existují best practices, které jsou do určité míry koherentní. V linuxu naopak často vidíte bastl poskládaný z filozofie různých distribucí i z různých dob, a pak laické dotazy typu "ono mi to funguje, ale JENOM BYCH potřeboval poradit ..."...
U obou systémů platí, že v první řadě musíte vědět 1) čeho chcete dosáhnout, 2) jak má aspoň přibližně vypadat cílové řešení, a teprve 3) můžete hledat nástroje. Body 1 & 2 si profesionálové chrání bez ohledu na platformu, a možná ani ne tak z chamtivosti, ale prostě protože nemají čas, náladu a potřebu se vybavovat s lidmi, kteří přijdou jen nasát znalosti a sami ničím neobohatí. To je důvod, proč to pak končí na komerční bázi běžného školení.
-
Problem spociva predevsim v tom, ze widle spoustu veci umej, ale neumej je aplikace, pripadne je neumi jejich GUI. V tomhle pripade je to pak jeste kombinovany s tim, ze narozdil od tuxe, kterej bere USBckovej disk jako kazdej jinej disk, to tak widle nevidej.
Mimochodem, po vytvoreni vice partysen na USBcku je naprosto nezbytny znemoznit widlim spoustet opravu disku. Tak to spolehlive zmrvi.
Podobna sranda pak jsou "dlouhy nazvy" ... kde si user typicky nabije hubu, kdyz jsou delsi nez 260 znaku ... nebo kdyz se rozhodne pouzivat nabodenicka (na nazvy tech souboru) a pak zjisti, ze podle toho z ktery zadele do toho vleze, dostane jiny kodovani.
-
A není jednodušší nesnažit se do jakéhokoliv systému, programu či čehokoliv lámat něco, co nepodporuje? Přecijen s linuxem jdu od jádra 1.2.x, s Windows od 3.0, a nikdy jsem nepotkal ani u sebe ani u zákazníků usecase, kdy bych nevyhnutelně potřeboval na jednu flashku kombinovat takovou opičárnu. Základem je po software nechtít nic, co nepodporuje, jen s utkvělou představou, že já jsem přesvědčen, že to má fungovat.
Například cestu > 260 znaků jsem u uživatele nepotkal nikdy, protože běžné operace v systému to prostě nepovolí. Podobně jako nějaké rozpadlé znakové sady u názvů souborů, neb snad od NT 4 to jede v unicode.
By mě zajímalo, jaké opičárny vymýšlíte, pokud se vám to stává tak často, že to stojí za zmínku.
Takže odpověď původnímu tazateli je: a) používat to, co systém podporuje, buďto přes GUI nebo CLI, nebo b) smířit se s tím, že ostatní situace se mohou chovat nevypočitatelně (a měnit své chování v čase).
-
Například cestu > 260 znaků jsem u uživatele nepotkal nikdy, protože běžné operace v systému to prostě nepovolí.
Jinak receno, vzivote si nikdy nevidel samba share (napriklad) ze? To se asi nemas moc cim chlubit ...
On totiz uzivatel A muze videt neco jako u:\pepa\mujuzasnysoubors260tiznakyvnazvu .... .doc ... zatimco uzivatel B muze videt x:\bandatupcu\marketing\pepa\...
Pricemz to ani zdaleka neni jediny mechanismus. Ono totiz bohate staci ... kdyz nekdo zmeni ten folder "pepa" ... na "pepicekmadnesnarozdeninytakmuprejemvsechnonej" ... coz widle naprosto vpohode dovolej ... ale to co je uvnitr uz se otevrit/kopirovat/presunout ... razem neda.
Coz opet svedci o tom, ze jak to (ne)funguje nemas ani paru. Z hlediska ntfs je to naprosto koser, protoze to zvada 32k.
-
Proč bych proboha dělal takový nepořádek mapování? Když už desítky let je prioritou UNC cesta, asi deset let DFS?! Když už musim mapovat shares, tak si snad pohlídám, abych v tom neměl takový šílený hokej, jak píšete.
-
Dik za potvrzeni, za blabolis o veceh, o kterych nemas ani paru.
Ty zjevne nic netusis o pravech, o tom, ze ruznych folderu nazdilenych pro ruzny skupiny uzivatelu jsou klidne tisice a jestli se pouzije \\cosi\pepa nebo u:\pepa je (z tohodle pohledu, jinak ne)* uplne jedno, naopak, ten nazev serveru se do tech znaku pocita taky, coz samozrejme taky nevis.
*Jedno to neni, protoze jsou aplikace, ktery si sitovej disk prevedou na UNC a jiny ktery si to tak neprevedou a s UNC vubec fungovat neumej(treba MS office). A neexistuje na tyhle planete uzivatel, ktere by to umel pouzit sam bez toho pripojenyho disku.
Ad DFS ... to mi vysvetli, jak to souvisi s delkou cesty? Snad leda tak, ze zcela z cesty blabolis.
-
A není jednodušší nesnažit se do jakéhokoliv systému, programu či čehokoliv lámat něco, co nepodporuje?
Jestli problém nebude v tom, že MS světě jedna komponenta něco podporuje, zatím co druhá, která na ní závisí, už nikoliv a ve výsledku je ten systém jeden velký nekonzistetní bordel. Například NTFS (jehož poslední verze je dle wikipedie z 2001) pracuje s názvy souborů v režimu case sensitive a podporuje v názvech souborů speciální znaky typu /\:*"?<>|. Zatím co ani aktuální WinAPI výše uvedené znaky v názvech souborů nepodporuje a pracuje s názvy souborů jako case insesitive. Výsledkem je, že tyto tvě core componenty Windows nejsou vzájemně plně kompatibilní se všemi negativními důsledky. A za to fakt nemůže uživatel, který si na NTFS oddíl v jiném OS nahraje soubory, které pak Widle kvůli nekompatibilnímu názvu neumí přečíst.
-
Jo, to jsem jednou nedopatřením udělal - v linuxu screenshoty so souborů typu screenshot_DD.MM.YYYY_HH24:MI:SS.png. Uložilo se to OK, ale Windowsy, přestože to viděly, s tím ani za boha nedokázaly nic udělat :). Holt dvojtečka je na oddělení disku v cestě, to Linux nepotřebuje.
-
Proč bych proboha dělal takový nepořádek mapování? Když už desítky let je prioritou UNC cesta, asi deset let DFS?! Když už musim mapovat shares, tak si snad pohlídám, abych v tom neměl takový šílený hokej, jak píšete.
To ani nemusíš. Ono úplně stačí, když nějakej jantar udělá mnohaúrovňovou strukturu složek, vylepší to diakritikou, a pak se nad tím pokusíš spustit nějakou konzolovku, ideálně ještě v nějakým dávkovým řetězci, kde se operace budou lišit podle toho, na který složce je budeš provádět = budeš potřebovat ty cesty nějak filtrovat. Dostaneš to v různým kódování nejen podle toho, jestli to spustíš přes CMD nebo PowerShell, ale bude se to často lišit i podle verze systému a jestli to budou wokna 64bitový nebo starý 32bitový desítky, 7/2008, nebo XP/2003. A jako bonus se to bude lišit podle toho, jak má dotyčnej uživatel, pod kterým se to spustí, nastavený regionální nastavení. A kdyby to nebylo málo, tak se to ještě umí lišit podle toho, jestli to spustíš z CMD spuštěnýho interaktivně (tzn Win+R, CMD.exe, <tvoje_dávka>.cmd), nebo jestli <tvoje_dávka>.cmd spustíš z něčeho, co už běží.
A další veledílo jsou komprimovaný složky, kterejm ve 2024Q4 s velikou slávou přidali podporu RARů a 7z. Ono to totiž umí jen některý komprimační metody a vůbec to neumí zaheslovaný archivy, což by byl ten menší problém. Ten větší problém je, že to má daleko větší omezení hloubky vnoření struktury složek v archivu, než ty origo archivátory, takže se ti může stát, že i když si při balení originálním 7zipem dáš bacha abys to nezahesloval a nepoužil LZMA2 na Ultra do solid archivu s blokem větším než tuším 1GB a slovníkem větším než 128MB, tak to na druhým konci samotnejma Windowsama stejně nerozbalíš, protože máš přešvihnutou maximální očekávanou hloubku vnoření nebo délku cesty uvnitř archivu, nebo nějaký podobný srandičky.
-
*Jedno to neni, protoze jsou aplikace, ktery si sitovej disk prevedou na UNC a jiny ktery si to tak neprevedou a s UNC vubec fungovat neumej(treba MS office). A neexistuje na tyhle planete uzivatel, ktere by to umel pouzit sam bez toho pripojenyho disku.
Úplně by stačilo zmínit CLI utility v samotnejch Windows. Některý UNC cesty umí, některý ne, některý tak napůl. Ve výsledku je nejlepší při jejich používání preventivně SUBSTovat.
-
Například NTFS (jehož poslední verze je dle wikipedie z 2001) pracuje s názvy souborů v režimu case sensitive a podporuje v názvech souborů speciální znaky typu /\:*"?<>|. Zatím co ani aktuální WinAPI výše uvedené znaky v názvech souborů
(...)
nahraje soubory, které pak Widle kvůli nekompatibilnímu názvu neumí přečíst.
To má jednoduchý zdůvodnění. Zpětná kompatibilita. MS chce, aby i na aktuálně 2025kách fungovaly bambilión let starý věci, který si naprogramovali korporátní zákazníci, takže z pohledu uživatele se to musí chovat navenek furt stejně.
Čistší řešení by asi bylo obdobný tomu, co udělal Apple při přechodu z Power na Intel a teď znova při přechodu z Intelu na ARM, tzn. emulační vrstva, pod kterou by se starý věci spouštěly. Apple je důkazem že to jde, otázkou je, jestli to na Windowsech je s ohledem na korporát schůdný.
-
Pokud chtějí zpětnou kompatibilitu, proč ji implementují jen na úrovni WinAPI a nikoliv na úrovni NTFS. To nedává žádný smysl, a jen to způsobuje problémy.
-
Třeba proto, že ty starý věci znají jen WinAPI32 a nic víc nikdy umět nebudou?
To by ses asi musel zeptat jich.
Zpětná kompatibilita je koule na noze, a moc dobře si to uvědomujou, ale jejím zahozením by riskovali ztrátu spousty zákazníků. Nepochybuj, že jakmile se to stane ekonomicky nerentabilním, zbývající zákoše hodí bez milosti přes palubu a zpětnou kompatibilitu zaříznou.
-
To ale není odpověď na otázku, proč NTFS v aktuální verzi podporuje case sensitive a specialní znaky v názvech souborů, když to žádný OS ze světa MS od 2001 nikdy nepodporoval a nejspíše ani podporovat nebude. Zpětná kompatibilita je naopak přesně ten argument, proč to na úrovní NTFS v současné verzi nepodporovat.
-
Na záměry by ses musel zeptat opět v MS. Možná to jen chtěli mít aspoň na úrovni FS "správně" s tím, že se to časem využije. Klidně to může využívat systém pro svoje záležitosti a uživateli to nezpřístupnit, ale to je jen spekulace.
-
To ale není odpověď na otázku, proč NTFS v aktuální verzi podporuje case sensitive a specialní znaky v názvech souborů, když to žádný OS ze světa MS od 2001 nikdy nepodporoval a nejspíše ani podporovat nebude. Zpětná kompatibilita je naopak přesně ten argument, proč to na úrovní NTFS v současné verzi nepodporovat.
Protoze design NTFS je odvozen od HPFS a pochazi z doby, kdy se o rade NT teprve koncepcne debatovalo a nebylo rozhodnuto ani jak tesne bude rada NT na OS/2 navazovat ani jak daleko od OS/2 se odvine/odkloni.
PS Kdybych se zeptal: Proc linux umoznuje ukladat na cizi souborovy system NTFS soubory s nazvy, ktere jsou na nativnim OS nepodporovane, to by byl ficak, ze jo :)))
-
Protoze design NTFS je odvozen od HPFS a pochazi z doby, kdy se o rade NT teprve koncepcne debatovalo a nebylo rozhodnuto ani jak tesne bude rada NT na OS/2 navazovat ani jak daleko od OS/2 se odvine/odkloni.
Všimnul jste si, že od té doby vydali vydali 5 verzi NTFS a v žádné nebyli schopni to "opravit"?
PS Kdybych se zeptal: Proc linux umoznuje ukladat na cizi souborovy system NTFS soubory s nazvy, ktere jsou na nativnim OS nepodporovane, to by byl ficak, ze jo :)))
Protože se tradičně drží specifikace? Jakýkoliv jiný přístup vede k totálnímu bordelu. NTFS z rozhodnutí MS je case sensitive podporuje speciální znaky, proto ovladač ntfs3 podporuje totéž. To je problém MS, že to má "rozbité". Úplně totéž platí třeba pro USB disky Seagate, USB/SATA převodník odporuje standardní SATA specifikaci, a driver tak má vypnutý UAS, dokud si to Seagate milostivě neopraví což se už delší dobu neděje.
Mimochodem aktuální ntfs3 ovladač má k dispozici přepínač "windows_names", takže tento souborový systém lze připojit tak, že ovladač vynutí všechna omezení odpovídající WinAPI.
-
Všimnul jste si, že od té doby vydali vydali 5 verzi NTFS a v žádné nebyli schopni to "opravit"?
Neni co opravovat (ani "opravovat"). Microsoft Windows je uzavrena platforma, pokud to nevite.
Protože se tradičně drží specifikace? Jakýkoliv jiný přístup vede k totálnímu bordelu. NTFS z rozhodnutí MS je case sensitive podporuje speciální znaky, proto ovladač ntfs3 podporuje totéž. To je problém MS, že to má "rozbité". Úplně totéž platí třeba pro USB disky Seagate, USB/SATA převodník odporuje standardní SATA specifikaci, a driver tak má vypnutý UAS, dokud si to Seagate milostivě neopraví což se už delší dobu neděje.
Jake specifikace? MS uz zverejnil oficialni specifikace? Podporuje ntfs3 ovladac transakce? Quoty? Shadow Copy? Ja jenom, aby nevznikl totalni bordel :)
Mimochodem aktuální ntfs3 ovladač má k dispozici přepínač "windows_names", takže tento souborový systém lze připojit tak, že ovladač vynutí všechna omezení odpovídající WinAPI.
No super, at to teda daji jako vychozi volbu. Jinak bezni uzivatele budou stale trpet :)
-
To je problém MS, že to má "rozbité".
Ale MS to nemá rozbitý. Když si koupíš auto s asistentama (a nový už si bez nich v EU koupit nemůžeš), a nebudeš je z vlastního rozhodnutí používat, znamená to snad, že máš auto "rozbitý"?
-
Mimochodem aktuální ntfs3 ovladač má k dispozici přepínač "windows_names", takže tento souborový systém lze připojit tak, že ovladač vynutí všechna omezení odpovídající WinAPI.
No super, at to teda daji jako vychozi volbu. Jinak bezni uzivatele budou stale trpet :)
Define "běžný uživatel". Podle mojí zkušenosti "běžný uživatel", který přechází mezi woknama a linem, má soubory buď na serveru (kam z woken leze SMBčkem a z lina většinou taky, výjimečně NFS), nebo na přenosným médiu formátovaným v drtivý většině FAT32.
-
Neni co opravovat (ani "opravovat"). Microsoft Windows je uzavrena platforma, pokud to nevite.
Jak to souvisí se skutečností, že core Microsoft komponenta WinAPI plně nepodporuje všechny funkce jiné core Microsoft komponenty NTFS?
Jake specifikace?
Pochopitelně ty co Microsoft zveřejnil. Snažíte se to okecávat marně. Diskutovaná funkcionalita je veřejně známá desítky let. To, že ntfs3 nepodporuje nějakou undocumented nebo secret feature je především problém samotného Microsoftu - je to jejich produkt. Kdyby chtěli, tak tu podporu naimplementují. Nikdo to za ně dělat nebude zejména proto, že mimo Widle nikdo příčetný NTFS používat nebude (navíc moderní FS jsou dnes někde úplně jinde) a pro specifické případy "migrace" dat současný stav dostačuje.
No super, at to teda daji jako vychozi volbu. Jinak bezni uzivatele budou stale trpet :)
To vskutku brilantní dedukce. Aby uživatelé Windows "netrpěli", tak vývojáři Linux kernelu by měli něco opravit :D
NTFS podporuje POSIX namespace, je to jeho standardní funkce, proto se při pripojení k POSIX OS používá. Ostatně tak si to MS sám navrhnul. Problém je čistě na straně WinAPI, které z nějakého důvodu nedokáže v rámci NT namespace s POSIX subsystemem pracovat. Tenhle problém je čistě na straně MS a jeho opravy se asi nedočkáte.
Jediné, na čem se asi shodneme je fakt, že přepínač "windows_names", který byl jako mount option dlouho k dispozici už v ntfs-3g by z praktického hlediska mohl/měl být výchozí. Ale to je workaround a nikoliv řešení problému. který leží někde úplně jinde.
-
To ale není odpověď na otázku, proč NTFS v aktuální verzi podporuje case sensitive a specialní znaky v názvech souborů, když to žádný OS ze světa MS od 2001 nikdy nepodporoval a nejspíše ani podporovat nebude. Zpětná kompatibilita je naopak přesně ten argument, proč to na úrovní NTFS v současné verzi nepodporovat.
Protoze mas spatnou predstavu o tom jak MS funguje ... spoustu toho, co je soucasti jejich systemu nebo aplikaci ... ve skutecnosti nekde koupili nebo ukradli. I to co pisou sami nepise MS ... ale nejaky z bambilionu oddeleni. A ruka tam pochopitelne nevi co dela noha. Takze proste nekomu prislo fajn mit case sensitive fs ... uz jen proto ze ti to pak poskytuje treba ruzny moznosti nazvovani prave velikosti pismen ... a nekdo jinej konstatoval ze to by byl bordel.
A predevsim na FATce to nefungovalo a useri by to neprezili.
-
O fungování MS nemám žádné iluze, proto tvrdím, že Widle jsou jeden velký bordel. ;D