Hvorfor kan Linux-systemer undertiden gendanne data Windows ikke?

Hvorfor er det, at du kan bruge en Linux-baseret computer eller Linux Live CD til at gendanne data, Windows ikke kunne?

Dagens Spørgsmål & Svar session kommer til os med venlig hilsen af SuperUser-en underafdeling af Stack Exchange, en community-driven gruppe af Q & A-websteder.

Spørgsmålet

SuperUser-læser Philip Allgaier vil vide, hvorfor han var i stand til at gendanne data med en Linux Live-cd, der blev rapporteret som uoprettelig i Windows:

Baggrund: Tidligere i år havde jeg et problem med et SSD-drev, som Windows ville genkende længere. Men i sidste ende en bootable Parted Magic 2012-10-10 gjorde tricket. Se denne løst tråd. Et spørgsmål fast med mig fra det øjeblik

Spørgsmål: Jeg er klar over, at Linux generelt er lidt mere teknisk og rå, men kan nogen omhyggeligt skitsere, hvorfor et Linux-system (eller faktisk kun den ene siden Ubuntu ikke gjorde det trick) stadig kan få adgang til / kommunikere med en halv -korrekt enhed, når Windows ikke er?

Kan de bare ignorere eventuelle indikatorer for at noget kan være forkert?
Er der nogen konkrete grunde overhovedet?
Var det bare held og lykke, at dette særlige miljø var i stand til at få SSD'et til at reagere, hvis det kun var i et begrænset tidsrum?

Selv om det helt sikkert kunne have været held, er der sandsynligvis mere end nogle få faktorer til spil. Lad os undersøge.

Svaret

SuperUser bidragyder Eike tilbyder nogle potentielle forklaringer ud over bare held, for hans evne til at gemme dataene:

Normalt kommer dette til, hvad der nøjagtigt er adgang til, og hvordan, præcis, enheden fejler. Hvis f.eks. SSD'en ikke er i stand til at hente, siger sektor 5 og begynder at stoppe, så snart som hvad som helst sektor 5, kan forskellen simpelthen skyldes, hvilke forskellige systemer der automatisk kommer adgang til, når de genkender en ny disk.

Når Windows registrerer en ny disk, vil den læse partitionstabellen og automatisk forsøge at åbne filsystemer, som den ved, hvordan man læser. Hvis nogen af de strukturer / blokke, der læses under denne "montage" -proces, udløser din fejlbehæftede SSD for at sige farvel, er forskellen med den specifikke Linux-distribution simpelthen, at den ikke automatisk kan montere alle de pågældende partitioner eller måske, når du monterer, skal du bare læse en anden delmængde af sektorer (implementeringen af NTFS i Linux er meget forskellig fra den i Windows - mens diskformatet er det samme, er det op til OS'et, hvilke strukturer det anser for nødvendigt at læse. Windows kan læse sekundære kopier af MFT, eller det kan begynde at forklare nogle data, og det kunne være forskellen. Ubuntu er i en lignende båd - den er ikke gearet til genopretning ud af kassen, det vil forsøge at montere ethvert filsystem, det finder på nyopdagede medier automatisk. Det er derfor, at specialiserede distributioner gearet til opsving er et bedre spil, da de kun gør hvad du udtrykkeligt beder dem om i modsætning til at gøre ting automatisk.

Selvfølgelig kan du bare have haft heldige også. Jeg ved ikke nok om SSD's svigtmodus at sige.

Linux ignorerer generelt ikke indikatorer om at noget er forkert. Det vil modtage de samme SCSI fejl fra SATA chipset som Windows vil - hvis du kigger på kernel loggen, på en defekt disk vil du se mange fejlmeddelelser. Det afhænger af, hvilke programmer der aktuelt kommer til disken, hvad der vil ske næste gang. Hvis det er software, der er rettet mod opsving, kan det forsøge at genlæse samme sektor et begrænset antal gange, det kan springe over det osv. Normalt er det bedste valg at få et billede af drevet med så mange sektorer som muligt at læse, og prøv derefter at gendanne dine data fra det billede (gør en analyse direkte på drevet er en dårlig ide, da det normalt kan forværres, og bare fordi du kunne læse noget en gang, betyder det ikke, at du vil kunne læse det igen .)

Medleverandør AthonSfere, tilbyder en anden udfordring:

Meget af det er, hvordan miljøet håndterer filsystemet, og ACL'erne eller harddisken.

Windows skal gøre alt, hvad det selv kan, for at adlyde sine ACL'er og sektorer markeret som dårlige eller tomme. Så NTFS eller Fat partitioner oprettet og vedligeholdt i Windows samt Windows MBR'er vil blive håndteret af Windows, da Windows markerede det.

Også, hvis drevet svigter jo mere du bruger det, desto mere sandsynligt er det at støde på et stort problem, og miljøet vil gå ned. Så hvordan operativsystemet håndterer, der kommer i spil, Windows vil BSOD eller genstarte, Windows-opstartsprocessen vil smide MBR-meddelelser, manglende filbeskeder (NTDLR.dll mangler eller korrupt) og stoppe, fordi disse dårlige filer er påkrævet.

Når du bruger en live disk, er du ikke afhængig af noget af dette. En dårlig MBR er omgået, fordi du starter fra disken. En dårlig sektor, der ødelagde NTDLR.dll, er ikke nødvendig. Alt er på disken. Du kan så prøve en læsning. Hvis det møder en 'blank' sektor eller dårlig bit, håndterer dette miljø det, men det var programmeret til at gøre. Ubuntu sandsynligvis vil hellere opretholde normale OS-adfærd og fortsætte med, hvad der mest sandsynligt vil ske. Sektoren er tom, gør noget andet. Den sektor er dårlig, holde sig væk, ikke læse igen, skriv ikke, eller det vil medføre problemer.

En recovery platform vil imidlertid gerne læse alle data. Filmarkørerne siger, at filen skal være på 0,5, 13 .... Hvis filsystemrapporterne 13 mangler, ignorerer du den tomme overskrift og læser filen alligevel eller læser den dårlige sektor så godt som muligt og forsøger at komme sig.

Windows kan også gøre meget af dette med tredjeparts applikationer. Recuva kan finde en masse af disse "manglende" filer, for en. Men du ønsker ikke at være i et miljø, der kan skrive tilbage til disken og forårsage sandt permanent tab.

Jeg forenklet dette og tilføjer nogle fortolkninger, men det skal udfylde nogle emner for hvad du spørger.

Har du noget at tilføje til forklaringen? Lyde af i kommentarerne. Vil du læse flere svar fra andre tech-savvy Stack Exchange brugere? Tjek den fulde diskussionstråd her.

http://superuser.com/questions/586666/why-can-linux-systems-sometime-recover-data-windows-cant-any-concrete-reasons