Jestli je to fragmentovaný FAT systém a smázneš si FAT tabulku, tak už to podle mě nedá dohromady ani pánbůh. Prostě se ztratil celý popis, jak jdou sektory souboru za sebou. S tím nejde nic dělat. Právě proto lidi vymysleli lepší souborové systémy než FAT, s kterým někdy v roce 1977 příšel Microsoft pro PC založené na i8080 s 64KB paměti ... (Wikipedia)
Kolik je FAT tabulek na paměťové kartě? Jsou foťáky, co umí třeba ZFS? :-)
Jaký filesystém měl CP/M? Já vím, že neměl adresáře a oddíly, ale nějak to přece na disk musel ukládat.
Jo stará éra slušovických TNS... CPM bylo (asi) přímým předchůdcem FAT, protože adresářový záznam se FAT dost podobal. Bylo to 32 bajtů, kde část 1. bajtu definovala uživatele (bylo jich 32), potom 8+3 znaků jméno a přípona, pak časové značky a příznaky (pořadí nepamatuji) a nakonec čísla sektorů. Dlouhé soubory byly ve vícero záznamech za sebou s tím, že to definoval ten 1. bajt. FAT byl vlastně totožný s tím rozdílem, že uváděl pouze 1. sektor (klastr) a definoval adresářový příznak. Přepnutí uživatele přepnulo selekci dle 1. bajtu a tím zpřístupnilo jiné soubory.
"Jestli je to fragmentovaný FAT systém a smázneš si FAT tabulku, tak už to podle mě nedá dohromady ani pánbůh."
No, prave jsem si myslel, ze clanek bude trab o programku, kterej vezme jednotlivy bloky dat (podle celkove velikosti disku pozna logickou velikost bloku FS) a pak bude jednotlive bloky na sebe zkouset pripojovat, jestli barevne sedi a podle toho by mohl vytvaret puvodni obrazky i na fragmentovanym systemu.
Jinak FAT ma dve kopie FAT tabulky (to je default a doufam, ze se nejaky zarizeni nesnazi byt chytrejsi a nedela jenom jednu), takze mozna i tam by mohlo neco pomoct. Navic, nezda se mi, ze by jakykoliv zarizeni pri zapisu dat na disk nacetlo celou FAT, vymazalo ji z disku, upravilo v pameti a zapsalo na disk. Osobne doufam, ze to precte max. jeden sektor, v nem udela zmeny a ty pak zapise. Znamenalo by to, ze by se neztratil cely obsah, ale pouze onen soubor, ktery byl zapisovan.
Jinak dobra praxe pri zapisu na karty a dalsi externi zarizeni je, po zapisu a odpojeni zarizeni tohle zarizeni znovu pripojit a aspon letmo zkontrolovat pocet a nazvy souboru s originalem a v lepsim pripade delat checksumy.
> Navic, nezda se mi, ze by jakykoliv zarizeni pri zapisu dat na disk nacetlo celou FAT, vymazalo ji z disku, upravilo v pameti a zapsalo na disk. Osobne doufam, ze to precte max. jeden sektor, v nem udela zmeny a ty pak zapise.
Jenze pri zapisu do flash pameti je treba najednou zapsat pomerne velky blok (radove desitky kB) - to dela CF ci SD karta sama pri pozadavku na zapis sektoru. Pokud dojde k poruse pri zapisu, muze se poskodit cely takovy blok.
Neco takoveho se mi stalo s docela drahym fotakem Sony. Najednou hryz a pri mazani se seknul. Partisna a fatka nikde. Diky bohu FATka nefragmentovana a odnesly to jen fotky.Photorec nasel jpg podle hlavicek. Slava mu!
[kotyz@amargit ~]$ dd if=/dev/sdb of=/home/kotyz/zalohy/karta.img
dd: reading `/dev/sdb': Chyba vstupu/výstupu
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0,0469598 s, 0,0 kB/s
možná by bylo dobré se zmínit o ddrescure - dd pokud narazí na vadný sektor, tak se ukončí - ddrescue se dá nastavit, aby vadné bloky přeskočilo, zkusilo načíst X krát, než je přeskočí, umí číst odzadu a podobně - u karty to moc důležité asi není, ale u CD - DVD je to dobré
taky by se hodilo alespoň jmenovat další recover programy občas jeden zvládne obnovit trochu jiné data, než druhý - např: recoverjpeg, magicrescue, foremost
Jj, ale ddrescure na to jde preci jen o trochu fikaneji :) kopiruje plnou rychlosti po nejake velikosti, pokud narazi na chybu tak ji preskoci a jede dal. Po dokonceni pak jede v druhem cyklu po problemovych oblastech s znatelne snizenym mnozstvim najednou nacitanych dat a postupne tak problemove oblasti "upresnuje" az chybi opravdu jen ty casti, ktere chybi.
Asi chybná formulace v článku. Teď jsem photorec zkoušel, a roota samozřejmě potřebuje jen k tomu aby uměl pracovat s celými disky nebo partitions. Při spuštění jako "photorec /path/to/card.img" v něm fungují všechny funkce i pod běžným uživatelem.
Možná se už znění čláku změnilo, od doby co jste psali.. ale když autor píše toto: cituji:
Pokud hodláme pracovat přímo s kartou, budeme potřebovat práva nejvyššího (tedy roota) a bude nám samozřejmě stačit sudo
tak to nevyjadřuje žádné tvrzení o práci s obrazem, ba dokonce si můžete v detailu všimnout že syntaxe příkazu je pod normální uživatelem: $ photorec karta.img
FAT se pouzival zejmena v DOSu a obcas na disku bylo i nekolik dulezitejsich veci nez fotky z dovolene. Proto v te dobe byly k mani celkem sofistikovane nastroje na opravu disku, ktere si poradily s fragmentaci, chybami v sektorech a buhvi cim jeste. Takze neni treba vymyslet znovu kolo - zkusil nekdo takovou kartu prohnat treba disk doctorem?
To som chcel napisat. Takto primitivny sposob som pouzil asi pred 5 rokmi a napisal som si maly softich co jednoducho vsetko od JPG headra az po nasledujuci header writol do jedneho JPG suboru. Okrem jednej polovicatej fotky bolo vsetko OK. Ani ma nenapadlo ze by nieco take niekto mohol potrebovat.
Mazanie suborov islo obnovit dost dobre lebo to nemazalo seriu sektorov vo fat. Ak naozaj prides o FAT (obidve) tak si nahraty, obzvlast pri velkych diskoch.
Zajímavý nástroj, určitě velmi šikovný. Protože jsme v rodině nedávno tento problém (obnova z karty) řešili, zkusil jsem si představit, že by tento program měl použít můj otec (namísto aby to šoupnul k vyřešení mně).
Normální neIT člověk opravdu neví, jaká tabulka oddílů byla použita nebo v jakém souborovém systému původní karta byla. Pro takové lidi by určitě pomohla autodetekce. Neříkám, že by byla spasitelná a vždy zafungovala, ale poznat FAT od FAT32 nebo NTFS by nemělo být tak komplikované a použitelnost pro běžné lidi by se řádově zvedla. Ač to píšu pod tento konkrétní článek, dalo by se to vztáhnout na řadu silných a šikovných, avšak z hlediska uživatele poněkud cizí řečí mluvících aplikací.
to je fakt - ceny za kartu jsem viděl od 99 korun asi do 650 pro fyzické osoby, pro podnikatele i dráž.
vzhledem k tomu, že na fotky stačí například:
recoverjpeg /dev/sdb1
je to dobrej vejvar :)
ale dovedu si představit, že když přijedu z dovolený a náhodou smáznu fotky na kartě, tak něž abych to řekl manželce, tak udělám cokoli, abych je zachránil :)
Článek pěkný, ale nepochopil jsem tuhle větu: "Uživatelé MS Windows obvykle ani netuší, že by měli něco takového dělat."
Zrovna wokna docela řvou, když nekorektně odpojíte flashku. To, že lidé nečtou, co jim počítač píše, je věc druhá.
Kromě toho si nemyslím, že každý uživatel woken je naprostej pitomec, byť statisticky je mezi námi více BFU.
To je asi pripad od pripadu, ale ja treba znam uzivatelku, ktera vyrvala klasicky HDD v supliku za chodu. Az ve chvili, kdy ji rekli, ze je odpaleny motherboard, tak si uvedomila, ze to asi nebylo to nejlepsi :)
no, za jistych okolnosti je mozne hotsvapovat i klasicke PATA disky, ale urcite ne v normalnim supliku a v zadnem pripade pripojene primo k southbridgy (tj. k integrovanemu radici). Ale pokud je na pridavne karte nebo zakladni desce nejaky lepsi radic a suplik podporuje hostswap (tj. je mozne ho vypnou a pak teprve vysunout, ne jako ty potvory s klickem), je mozne celkem bezproblemove hostwapovat (tedy, alespon v Linuxu). Ja sam mam dobre zkusenosti s fakeraidy Promise, ale funguje to pry i s nekterymi chipy Silicon Image a HighPoint. Jen je treba mit ovladac jako modul a pred vyndanim disk tvrde uspat (hdparm -Y) a pak vyjmot modul pomoci rmmod.
nemluve o tom, ze disk lze i ve win pripojit jako 'optimalizovany pro okamzite vytazeni' tj po skonceni kopirovani lze okamzite vytahnout (a je to default pro bezne flasky). Jestli ho nekdo vytahne behem kopirovani, tak tomu nezabrani zadny operacni system :-)
Fámy o zničení flash medii veľkým počtom zápisov stále pretrvávajú? Testoval som jeden flash disk tak, že som ho používal ako /tmp viac ako 4 mesiace. Bez problému. Logika implementovaná vo flash mediách (má na starosti distribuovat dáta rovnomerne) si svoju prácu robí evidentne dobre. Tak isto aj počet opakovaných zápisov stúpol za posledné roky rádovo...
Podľa mňa je mechanické zničenie flash médií podstatne pravdepodobnejšie.
Čo je to "systémový disk se swapem"? Máš na mysli /, alebo /usr, alebo /usr/local?? Nepovedal by som že tam hrozí väčší počet zápisov ako na /tmp. Viem si predstaviť slušnú funkčnosť s prakticky ro /, /usr aj /usr/local
Swap? To už dlhšie nepoužívam. Ruku na srdce, dá sa pracovať so strojom ktorý swapuje? Aký veľký swap používaš? 512MB? Aj sa ti niekedy zaplní na viac ako 20%. Nie je jednoduchsie pridať 512MB RAM?
Co to tu plácáš za nesmysly. Když jsi to chtě pořádně otestovat, tak jsi měl použít swap, i když ho normálně nepoužíváš. Jen pro test. A se zbytečností swapu bych zapochyboval. Programy rády bobtnají a leakujou a tuhle zbytečnou pamět je nejlepší uložit do swapu. A jeste k tomu swapu a dokupování RAM. Mám 4 GB RAM a 5 GB swap a i přes to mám někdy swap plný z více než 50%.
1) Len som reagoval na to že diskutujúci tvrdil že sa zníži životnosť flash média častými zápismi....
2) "Mám 4 GB RAM a 5 GB swap a i přes to mám někdy swap plný z více než 50%"
Áno, máš pravdu, je to štandardná situácia...
Diky za zminku o sikovnem nastroji. Ale chtelo by to provest vice ruznych testu, nebo alespon se pokusit nasimulovat realnejsi situaci, kdy je na karte drobna fragmentace (protoze fotky se daji mazat i ve fotaku a klidne i z prostredka) a kdy jsou poskozena i dalsi mista na karte (v pripade vypadku napajeni fotaku nebude zrejme poskozena jen tabulka, ale i nejaka ta prave zapisovana / mazana data). Uvedeny priklad je dost umely a neni zadny div, ze data byla obnovena.
Fyzicky poskozenou kartu (treba nalomenou) bych do ctecky nedaval. Vazne hrozi zkrat a poskozeni v lepsim pripade ctecky, v horsim i neceho dalsiho. Sam jsem jednu takovou kartu videl a topila primo ukazkove.
Nema niekto tip na nejaky nastroj, schopny zachranit MPEG4 video z fotoaparatu (Oly 770UZ). Subor ma chybajucu resp. poskodenu hlavicku, inak sa zda byt ok.
D. za tip, vyskusal som trial, ale je to len recovery na urovni scanovania karty po blokoch a vyhladavania znamych typov hlaviciek - i.e. komercna GUI alternativa k toolu, popisanemu v tejto recenzii
zkus jednoduse prepsat hlavicku z jineho souboru, nekdy to zafunguje.
a ten mpeg4 je ve skutecnosti mjpeg, ne? pak jdou zachranit jednotlive snimky programama co najdou jpg.
no čekal jsem vícero utilit pro tyto případy a když sem viděl testdisk, tak mě pak přkvapilo že i o něm autor nepíše. testdisk mě několikrát zachránil, a zrovna před chvílí jsem ho použil na usb flashdisk, kterýmu sem za pomoci install-mbr přepsal místo 512B boot sektoru sda přímo oddíl sda1, což zlikvidovalo fs(fat). testdisk ovšem opět zabodoval a bez přemlouvání fat obnovil.
Jednou jsem resil problem s kartou a dokonce jsem snad ten testdisk pouzil, ale tusim, ze s nulovym ucinkem, odpoved je mozna prave v clanku, kde ocekava nefragmentovane data, coz je spis jen legracka, protoze v takovem pripade by byl program uplne k nicemu. Navic proc by ho pak zajimal filesystem, kdyz by nasel hlavicku a vsechno za ni ulozil do fajlu. Bud autor clanku neumi cist a nebo je program totalne k nicemu a nema smysl o nem vubec diskutovat, protoze nefragmentovane data? Lol! Mozna po formatu karty, ale ne po smazani souboru. Kazdopadne clanek kvalitativne odpovidajici rootu...
Jo a data jsem nakonec dostal nejakym softem, co to vyzral heuristicky a valnou cast zachranil. Proste vymakany soft, tudiz se pochopitelne nejednalo o opensource:)
co prvne provest uvahu: kdo zapisuje data na ten vfat? co treba radic flashky? uz dlouho se zvysuje zivotnost flashky prave tim ze se tam zapisuje dle jinych pravidel nez na hdd.
jinak by v pripade nevhodne zvoleneho fs (coz fat rozhodne je nevhodny - ma fat table na jednom miste.) by se urcite misto neustalym prepisovanim proste "vypalilo" a bylo by po vtakach.
> co prvne provest uvahu: kdo zapisuje data na ten vfat? co treba radic flashky? uz dlouho se zvysuje zivotnost flashky prave tim ze se tam zapisuje dle jinych pravidel nez na hdd.
To michas dve odlisne vrstvy - vrstvu logickych sektoru, ktere flash karta poskytuje a vrstvu fyzickych bloku, kde jsou data ulozena. Radic flashky rozhoduje o tom, ktery fyzicky blok se pouzije pro dany logicky sektor. Operacni system implementujici FAT vybere logicky sektor (resp. cluster) a vubec ho nezajima, na ktery fyicky blok to radic zapise. Z hlediska logicke fragmentace (coz je to, co vadi pri obnove souboru pri smazani FAT tabulky) ma smysl jen ta uroven logickych sektoru, tudiz plest sem radic flashky a wear-leveling je uplne mimo.
Distribuce zápisů přes celou kartu je z hlediska karty jako blokového zařízení transparentní. Čtěte: pokud budete přepisovat pořád jeden sektor karty, řadič karty zajistí, že se ve skutečnosti bude karta opotřebovávat rovnoměrně.
Hm, seznamim vas se svou manzelkou. Vyfoti dvacet fotek behem minuty, pak si na deset minut sedne, osmnact z nich smaze (podle LCD displeje na fotaku, prosim) a pak se presune fotit dalsi.
"Už se mi několikrát stalo, že mi některý šikovný známý vytrhl z počítače flashku bez odpojení. Uživatelé MS Windows obvykle ani netuší, že by měli něco takového dělat."
Uzivatele windows kteri nic takoveho doposud netusili mohou nadale zustat klidni, ponevadz nic takoveho jako odpojeni delat urcite nemusi. Windows XP ma totiz standartne pro vsechny prenosne zarizeni write cache vypnoutou a problemy popsane vyse by mohli nastat pouze pokud by uzivatel zarizeni odpojil behem zapisu na disk.
Computer management > Device Manager > Disk Drives > USB Storage Device > Policies > Optimize for quick removal
na svojich pocitacoch nastavenie vzdy prepnem na write cache mod, zapis sa vyrazne zrychli.
skoda ze MS default nastavuje opacne nastavenia, napr. taky autostart z flash zariadeni podporuje sirenie roznych virusov, takze "autostart virus feature" zase vsade vypinam.
Zápis se zrychlí jen v některých scénářích. Typicky u velkého množství malých souborů. Je ale třeba si uvědomit, že memory card je taková lepší disketa. Vadilo u disket, že byly opravdu velmi pomalé? No nevadilo. Memory cards jsou daleko rychlejší i s vypnutou write cache.
Autostart z flash zařízení pokud vím pouze nabídne dialog, autorun snad neprovádí. S překvapením jsem zjistil, že ten dialog s akcemi, co vyskočí po vložení média, někteří lidé fakt používají. Dokonce ty akce ani nejsou úplně nesmyslné. Přesto autoplay a auto* vždy vypínám.
ano, "zapis sa zrychli len pri niektorych scenaroch", ale kedze juzri vacsinou nechapu ze mozu pred ulozenim na usb kluc pouzit kompresiu tak je ten scenar v praxi realizovany velmi casto.
potom vidim cloveka s 60-rychlostnym usb klucom ako nan tlaci 100MB graficku kniznicu komponentov s tisickou malych suborov a rozculuje sa preco to ide tak pomaly ked 700MB film sa mu tam skopiruje pomerne rychlo.
na eliminovanie takychto juzrov mudre hlavy vymysleli write cache.
na eliminaciu takychto mudrych rieseni inzinieri v redmonde vymysleli defaultne vypnutie write cache.
dialog na vyber akcii je naviazany na typ media (audio cd / video dvd / data cd).
autorun sa spusti vzdy ak nie je vypnuty alebo ak pri mountnuti nedrzite shift a je nezavisly od toho dialogu na vyber akcii.
Pekny clanek.
Zajimala by me ale jedna vec. Kdyz program hleda zacatky souboru pomoci znamych sekvenci, jak poznava konec souboru? Proste tak usoudi podle toho, ze narazi na dalsi znamou hlavicku?
Co kdyz jde o flash disk, kde mam ulozene i jine typy souboru, ktere program nezna?
Nasype mi pak na konec jemu znameho typu souboru i tato data az do te doby nez narazi opet na znamou hlavicku?
Nejspis tim, ze prozkouma samotny soubor - nevim jak u JPEGu, ale u mnoha souboru je velikost dat primo v hlavicce, pripadne ji lze z hlavicky odvodit. A pokud ne, je mozne se pokusit struturu souboru (ttreba u JPEGu muze provest jeho dekompresy do nikam) a mnozstvi potrebnych dat prohlasit za velikost souboru.
U JPEGu je to hledání začátku a konce trivka. Obsahuje byty (v hex FFEF a FFE0) podle kterých začátek a konec vždycky najdeš a velikost je ti tedy celkem fuk.
Tak jsem se dnes rano vzbudil a prvni blbej napad, ktery me prepadl byl zazalohovat skripty zhruba za posledni mesic. Nahodil jsem Krusader a slozku se skryptama jsem ze serveru prekopiroval pres ssh na svuj pocitac. F8+enter vsak asi nebyl ten spravny postup pro kopirovani. Zhruba o minutu pozdeji sem se opravdu probral a vydesene koukal, co ze se to stalo :)
Nastesti jsem neveril tem recickam co jsem slysel, ze data z ext3 se nedaji obnovit a za par minut jsem vygooglil PhotoRec a dal se do instalace. Opensuse 10.3 ho nastesti maji v repozitari, takze otazka par sekund. Zkusil jsem obnovovat nejprve vse, ale moje lua skripty to nejak vynechavalo. Prosel jsem help k programu a o lua ani slovo. Po par minutach jsem zacal studovat zdrojove kody a malem je zacal i upravovat. Nastesti jsem zjistil, ze program umi i jine pripony, nez o kterych se pise. Lua skripty obnovil, ale dal jim priponu txt. Nebyl pak nastesti zadny problem jen prohledat nalezenych 200 000 txt souboru na retezce, ktere se vetsinou vyskytuji v lua skryptech.
Kdyz jsem ted zjistil, ze na rootu vysel clanek, tak jsem proste musel pridat tento komentar. :)
Program PhotoRec je opravdu spickovy a mohu jen doporucit.
Mam 1 GB SD kartu. Niekde v strede je 1/zopar vadnych blokov. FS je FAT koly fotaku. Je sposob, ako poskodene bloky najst a znefunkcnit, aby FS na nich nezapisoval?
Ak totiz nahravam povedzme 10 minutove video a prekryje prave tieto poskodene bloky, tak video sa da prehrat iba po najblizsi vadny blok.
Pripadne ak to nevie FAT, tak by som mohol kartu pouzivat uz iba v linuxe s nejakym inym FS.
Diky
FAT myslim zadne takove nastroje nema, ale mel by se o to starat radic flashky, jestli to nedela, tak nevim - leda zkusit do tech vadnych bloku "zapsat" nejaka data a tak ten fotak donutit je preskocit (zapsat = prepsat kus FAT tak, aby v tech sektorech opticky neco bylo, tohle myslim dela Windowsi chkdsk)
FAT tabulka může označit clustery obsahující vadné bloky (kódy 0xFF7,
0xFFF7 nebo 0x?FFFFFF7 pro FAT12, FAT16 respektive FAT32). Standardní
DOSový či Win příkaz format volaný bez parametru /F celou užitou plochu
média kontroluje a vadné bloky označí.
Pod Linuxem to přímo fdformat ani mkdosfs myslím neumožňuje. Je ale
možné použít parametr -t u příkazu dosfsck, který zkontroluje čitelnost
bloků a jim příslušející clustery označí za vadné.
K hledání špatných bloků lze využít i příkaz badblocks, který umí i test
se zápisem (nedestruktivní -n, destruktivní -w).
Na magnetická média je to dostatečné. Bohužel na Flash disku to asi
fungovat nebude, protože wear leveling má snahu využívat co nejvíce
různých fyzických bloků a postupně na ně zapisované bloky mapuje.
Na druhou stranu si kontrolér na kartě udržuje seznam vadných bloků.
Ten není prázdný ani u převážné většiny nových výrobků. Když koupíte
i samotný NAND Flash chip, tak má většinou již povícero bloků vadných
a příslušně označených. Výrobce jen garantuje, že maximum vadných bloků
je menší než nějaký počet, či procento.
Pokud je tedy chyba na úrovni fyzického bloku tak je potřeba, aby se
o vyloučení bloku z používání postaral již samotný kontrolér karty.
Ten takto označí i bloky, ze kterých se sice data přečíst podařilo díky
korekci chyb, ale vykazují tyto výpadky příliš často. Pokud to kontrolér
neudělá, tak je buď vadný nebo mu již došla kapacita rezervních bloků.
Co lze v takovém případě udělat nevím. Lze zkusit zmenšit velikost
používané oblasti/partition. Ve skutečnosti by bylo potřeba zmenšit
reportovanou kapacitu karty příslušnou parametrizací kontroléru.
K tomu ale nástroje kromě výrobce karty dostupné nebudou.
Ona také chyba může být úplně jinde. Foťák může mít někde studeňák, a díky tomu čas od času zapsat nesprávná data. Ad absurdum může jít o závadu firmwaru, který po přetečení nějaké interní variable dělá neplechu. Třeba některé telefony po nějakém tom roku užívání mají hromadu dříve neviděných bugů, které zmizí resetem na tovární nastavení. Dalelo pravděpodobnější je ale špatný kontakt karty nebo baterií, koroze způsobená třeba mořskou vodou, atd. Jestli je karta opravdu vadná, to lze zjistit třeba zformátováním s ověřením bloků (ve Windows format /f), a použitím skriptu který cyklicky zapisuje na kartu a kontroluje výsledek. Osobně bych si vsadil spíše na chybu foťáku, než chybu karty, byť vyloučit nelze ani jedno.
Tak zrovna resim problem s flashkou Porte 4GB. System "winxp" ji vidi jako F:, ale pri pristupu pise vložte disk. Nejde ani naformatovat. V linuxu ji take system najde jako /dev/sda a pri mountu pise "no medium found". Ani fdisk /dev/sda nezabira. Nesetkal se s tim nekdo? Neporadite?
Řeším stejný problém. Flashka funguje bez problémů pod uživatelem s právy admina, pokud flashku připojí k počítači běžný uživatel, při pokusu o přístup na disk systém výpíše hlášku vložte disk do jednotky X:
Mechanicky je flashka v pořádku. Problém je jinde. Teoreticky bych mohl přidat admin práva uživatelům, ale to bych musel být padlý na hlavu (počítač je připojený k internetu, děti nemají páru co je to malware).
Ahoj, mám problém.
Při ukládání dat na flashku jsem ji asi vytáhla příliš brzy z počítače. Od té doby mi každý počítač, kam flashku zastrčím, hlásí, že disk není naformátovaný, a jestli jej chci naformátovat. Při otevření flashky v total commanderu se mi zobrazí hláška, že dist nebyl nalezen.
Nevíte někdo, zda-li by se dalo nějakým způsobem zachránit data na mé flashce?
Díky za pomoc...
Zdravím, mě vznikl jiný problém a zatím nemám žádné řešení. Při fotografování jsem používal k zálohování přenostný disk se čtečkou Vosonic. Bohužel jsem si nastavil maximální přenosovou rychlost na disku v jeho firmware. Soubory přečtu nicmémě tam mám občas posun barevný i pixelový. Není to u všech fotek. A vypadá to, že informace v souboru jsou všechny. Je to jako by si tam přidal pár bytů při zápisu z karty na disk. Někde jsem četl, že se to stává. Bohužel jsem nenašel SW, které by to řešilo. Jít bit po bitu v hexaeditoru je dost blbá práce. I když ručně pokud se dá najít dané místo lze fotku opravit. Neřešil jste někdo podobný problém?
NO ne vždycky to funguje, vyfotil jsem mobilem fotku a pak mi nějak nešla nahrát a celá paměťovka se nějak pokazila. Skoušel jsem to přes tento program a nic, nemáte ještě někdo jiný postup?
Naprosto mě to zachránilo! Veškerá data se mi podařilo po stažení asi 5ti programů obnovit právě tímto a to i tehdy, když nejsem nijak zvlášť technicky zdatná.