Na WINHEX jsem si nevzpomněl, to vypadá jako dost mocný nástroj. Po návratu vyzkouším.Původně odesláno od Dojigiri
Defraggler soubory na místě ukazuje. Jenže neukazuje, kde je vadný sektor. Tím jsem právě myslel tu mapu disku v původním dotazu.
Ono je taky dost možný, že k žádné ztrátě dat ani nedošlo a v těch 4kB nic nebylo. NTFS má snad nějaké kontrolní mechanizmy, ale fakt netuším...
Hmmm, nejsem si jistej, ale furt mi tu nehraje jedna věc.
Ty si ty data přehrál? A neřvalo to u žádnýho souboru? Pak imho data poškozený nejsou, nebo sou poškozený tak, že to nepoznáš (disk sektor blbě přečet a realokoval s blbejma datama). Kdyby byl soubor při kopírování přes badblock, tak by to přeci řvalo při jeho čtení, ne?
No ono je možný, že když na tom byl spuštěn chkdsk a nemoh ten sektor přečíst, že ten soubor odstanil z MFT, takže byl "smazán". Takže při kopírování pak ten soubor vůbec kopírován být nemusel.
NTFS má žurnálování, což je ale spíš věc pro případ nečekanýho pádu systému, vadný bloky bych řek že opravit (ani detekovat) nedokáže. A jeho implementace (resp. vůbec celýho NTFS) taky není nějak zvlášť odolná, protože se stává docela často, že při takovým výpadku dojde k poškození prvního sektoru NTFS jednotky (boot recordu) a je třeba ho opravovat (osobně už jsem to opravoval několikrát a na fóru je tenhle problém taky vcelku často). Ale naštěstí je na jednotce jeho kopie, takže se s tím při návrhu tak nějak počítalo.
No, co se týká reklamace, většinou to asi moc neřešej a vyměňujou, ale v principu by to mohli i opravit tak, že na tom spustí ten hddregenerator a nechají to realokovat - proto tam ta nadbytečná oblast je a v podstatě se s tím počítá (když se nevyměňujou LCD s vadnými pixely do určitýho počtu, který navíc opravit ani nejdou, tak v principu není potřeba měnit hdd, když dokonce spravit jde a s realokací vadných sektorů se počítá). Ale pro obchodníka je asi jednodušší odeslat disk zpátky výrobci, než to řešit (zabralo by to nějakej čas a člověka kterej by to dělal by bylo třeba zaplatit).
NTFS má žurnál jen na metadata, nikoli na data. Takže vadný bloky neopraví.
CHKDSK by nic měnit neměl, pokud se nezadal s parametrem opravit, ale je to MS soft :-)
Pokud by tam byl/nebyl soubor, tak to jde srovnat se zálohou snadno (tolik datovejch souborů člověku zas nezaniká, aby to nešlo probrat ručně). Tazatel se imho spíš bojí, aby neměl v prostřed souboru blbosti z chybnýho a realokovanýho souboru. A tam se přiznam, že nevim přesně, jestli si disk když zjistí badsector dovolí i realokovat sám a zapsat tam to co přečte, nebo takovoudle věc musí uživatel udělat spešl (např. hdd regeneratorem, formátem s kontrolou povrchu atd...).
No, jedině že by si ten soubor nějak "dotvořil" sám operační systém např. při kontrole chkdsk anebo při kopírování ... protože co se týká SMART, tak ten pokud vím vadnej sektor nepřealokuje sám od sebe, pokud z něj nejde přečíst (neví totiž pak, co by měl vlastně pod přealokovanej sektor napsat). Pouze ho dá pod "offline uncorrectable" a čeká, až do něj systém znovu zapíše (což by přepsalo původní data, takže už pak není důležitý, co v nich bylo) - v tu chvíli ho přealokuje a zapíše data do novýho umístění. Pak by sektor měl zmizet z offline uncorrectable a objevit se pod reallocated sectors (ve SMART).
Pokud existuje předchozí záloha, tak potom lze pro úplnou jistotu porovnat soubory podle obsahu - např. Total Commander to umí (Příkazy/Synchronizovat složky, zaškrtnout Porovnat podsložky a Podle obsahu).
Víceméně vyřešeno.
Podle Winhexu byl v okolí nečitelného sektoru $LogFile a ne žádný datový soubor. Pravděpodobně teda k žádný ztrátě ani poškození dat nedošlo.
Ještě se ozvu později k posledním příspěvkům.
Check disk vytvára súbory s roztratenými blokmi v koreňovom adresári FILE0000.chk alebo tak nejak. Keď chcem vedieť, čo bolo poškodené otvorím to v notepade a vidím. Niekedy aj nevidím, ak to bol nejaký obrázok, alebo fragment multimediálneho súboru. Ale možno je celý tento môj príspevok od veci, lebo som to nečítal celé.
Odpovídat lze po přihlášení
