Hvorfor kan Linux-systemer noen ganger gjenopprette datavinduer ikke?

Hvorfor er det at du kan bruke en Linux-basert datamaskin eller Linux Live CD for å gjenopprette data Windows ikke kunne?

Dagens Spørsmål & Svar-sesjon kommer til oss med høflighet av SuperUser-en underavdeling av Stack Exchange, en fellesskapsdrevet gruppering av Q & A-nettsteder.

Spørsmålet

SuperUser leser Philip Allgaier vil vite hvorfor han var i stand til å gjenopprette data med en Linux Live CD som ble rapportert som uopprettelig i Windows:

Bakgrunn: Tidligere i år hadde jeg et problem med en SSD-stasjon som Windows ville gjenkjenne lenger. Men til slutt en oppstartbar Parted Magic 2012-10-10 gjorde kunsten. Se denne løste tråden. Et spørsmål fast med meg fra det øyeblikket ...

Spørsmål: Jeg er klar over at Linux generelt er litt mer teknisk og rå, men kan noen grove skissere hvorfor et Linux-system (eller faktisk bare den ene siden Ubuntu ikke gjorde kunsten), er i stand til fortsatt å få tilgang til / kommunisere med en halv -korrigert enhet når Windows ikke er?

Glemmer de bare noen potensielle indikatorer at noe kan være feil?
Er det noen konkrete grunner i det hele tatt?
Var det bare lykke til at dette bestemte miljøet var i stand til å få SSD til respons hvis det bare var for en begrenset periode?

Selv om det sikkert kunne ha vært flaks, er det sannsynligvis mer enn noen få faktorer på spill. La oss undersøke.

Svaret

SuperUser-bidragsyter Eike tilbyr noen mulige forklaringer, utover bare flaks, for hans evne til å lagre dataene:

Vanligvis kommer dette ned til det som nettopp nås, og hvordan, akkurat, enheten svikter. Hvis for eksempel SSD-en ikke er i stand til å hente si sektor 5 og vil begynne å stoppe så snart som noe leser sektor 5, kan forskjellen ganske enkelt skyldes hvilke forskjellige systemer som automatisk får tilgang når de kjenner igjen en ny disk.

Når Windows oppdager en ny disk, vil den lese partisjonstabellen og forsøke å åpne eventuelle filsystemer den vet hvordan man leser. Hvis noen av de strukturer / blokkene som leses under denne "monteringsprosessen" utløser den feilaktige SSD-en din, så er forskjellen med den bestemte Linux-distribusjonen ganske enkelt at den ikke automatisk kan montere alle partisjonene i spørsmålet, eller kanskje, når du monterer, les ganske enkelt en annen delmengde av sektorer (implementeringen av NTFS i Linux er svært forskjellig fra den i Windows - mens diskformatet er det samme, er det opp til operativsystemet hvilke strukturer den anser nødvendig for å lese. Windows kan lese sekundære kopier av MFT, eller det kan begynne å forklare noen data, og det kan være forskjellen. Ubuntu er i en lignende båt - den er ikke rettet mot utvinning ut av esken, det vil forsøke å montere hvilket filsystem det finner på nyoppdagede medier automatisk. Det er derfor at spesialiserte distribusjoner rettet mot utvinning er en bedre innsats, da de bare gjør det du eksplisitt ber dem om, i motsetning til å gjøre ting automatisk.

Selvfølgelig kan du bare ha blitt heldig også. Jeg vet ikke nok om SSDs feilmodus å si.

Linux ignorerer generelt ikke indikatorer på at noe er galt. Det vil motta de samme SCSI-feilene fra SATA-brikkesettet som Windows vil - hvis du ser på kjerneloggen, på en feil disk vil du se mange feilmeldinger. Det avhenger av hvilke programmer som nå får tilgang til disken, hva som skjer neste gang. Hvis det er programvare som er rettet mot gjenoppretting, kan det prøve å lese samme sektor et begrenset antall ganger, det kan hoppe over det osv. Vanligvis er det beste alternativet å få et bilde av stasjonen med så mange sektorer som det er lest, så rent som mulig, og prøv å gjenopprette dataene dine fra det bildet (å gjøre en analyse direkte på stasjonen er en dårlig ide, vanligvis siden tilstanden kan forverres, og bare fordi du var i stand til å lese noe en gang, betyr det ikke at du vil kunne lese det igjen .)

Medforfatter AthonSfere, tilbyr en annen ta på ting:

Mye av det er måten miljøet håndterer filsystemet, og ACLer eller harddisken.

Windows skal gjøre alt det kan i seg selv for å adlyde sine ACLer, og sektorer merket som dårlige eller tomme. Så NTFS eller Fat partisjoner opprettet og vedlikeholdt i Windows samt Windows MBRs vil bli håndtert av Windows når Windows markerte den.

Også, hvis stasjonen svikter jo mer du bruker det, desto mer sannsynlig er det å møte et stort problem, og miljøet vil krasje. Deretter hvordan operativsystemet håndterer som kommer inn i spill, Windows vil BSOD eller reboot, vil Windows-oppstartsprosessen kaste MBR-meldinger, manglende filmeldinger (NTDLR.dll mangler eller korrupter) og stopper fordi disse dårlige filene kreves.

Når du bruker en levende disk, stoler du ikke på noe av dette. En dårlig MBR er omgått fordi du starter opp av disken. En dårlig sektor som ødela NTDLR.dll er ikke nødvendig. Alt er på disken. Du kan deretter prøve å lese. Hvis det møter en "tom" sektor eller dårlig bit, håndterer miljøet det, men det var programmert til å gjøre. Ubuntu sannsynligvis vil helst opprettholde normale operativsystemer og fortsette med det som mest sannsynlig skjer. Sektoren er tom, gjør noe annet. Den sektoren er dårlig, holde seg borte, ikke les igjen, skriv ikke, eller det vil føre til problemer.

En gjenopprettingsplattform vil imidlertid ønske å lese alle dataene. Filmarkørene sier at filen skal være på 0,5, 13 .... Hvis filsystemrapporteringene 13 mangler, ignorerer du den tomme overskriften og leser filen uansett, eller les den dårlige sektoren så godt som mulig, og prøv å gjenopprette.

Windows kan også gjøre mye av dette med tredjepartsprogrammer, Recuva kan finne mange av disse "manglende" filene, for en. Men du vil ikke være i et miljø som kan skrive tilbake til disken og forårsake ekte permanent tap.

Jeg forenklet dette, og legger til litt tolkning, men det skal fylle ut noen emner for det du spør.

Har du noe å legge til forklaringen? Lyde av i kommentarene. Vil du lese flere svar fra andre tech-savvy Stack Exchange-brukere? Sjekk ut hele diskusjonstråden her.

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