Reparera NTFS?
Johan Plane
filsystemet på en av mina hårddiskar är väck - anger att formatet är
RAW. Vid avstängningen var det NTFS.
Det är inte min bootdisk, så det problemet har jag inte, men det är min
största hårddisk och det skulle vara trist om allt gick förlorat.
Finns det något sätt att reparera den så att windows kan identifiera
NTFS igen utan att formattera om den?
Johan
Olof Lagerkvist
Det brukar oftast betyda att Windows av någon anledning inte uppfattar
den som samma storlek som tidigare (annorlunda geometriemulering). Detta
kan komma av att den tidigare var inställd i BIOS på något visst sätt
och nu inte listas av BIOS alls utan Windows-drivrutinen undersöker
diskstorleken själv, eller tvärtom, eller att den nu sitter på ett annat
controller-kort som har annan geometriemulering som standard än den
tidigare controllern använde.
Förslag är då: Eftersom du inte bootar på disken kan du prova att se
till att BIOS inte hittar den alls och låta Windows självt avgöra hur
disken ska hanteras. Kolla också att diskhanteraren i Windows visar
disken med exakt samma storlek som den gjorde tidigare. Om inte är något
annorlunda inställt för drivrutinen eller disk-controller än det var
tidigare.
--
Olof Lagerkvist
ICQ: 724451
Web: http://here.is/olof
Charlie R
Du skulle kunna pröva DFSee. Det har räddat en partition åt mig som
var totalt förlorad (Partition Magic gick in i en oändlig loop när
jag flyttade en 16GB-partition 4GB OJMR). Med DFSee gick det att
få ordning på partitionen och rädda majoriteten av filerna på den.
(Det var inte NTFS utan HPFS).
Nackdelen med ett så potent program som DFSee är att man måste läsa
på _mycket_ noga innan man använder. Träna gärna på någon ersättlig
partition (det går att göra 'undo' i många lägen, men det är dumt
att förlita sig på att det ska fungera när man verkligen behöver
det.
Ladda hem utvärderingsversionen (en diskettimage) från
Charlie.
--
Steele's Plagiarism of Somebody's Philosophy:
Everybody should believe in something -- I believe I'll have
another drink.
Johan Plane
Disken sitter på ett extra controllerkort (Promise Ultra 133 TX2) eftersom
det är IDE-disk nr 4 i burken. Den har inte flyttats på fysiskt. Konstigt
nog: i BIOS identifieras den som en SCSI-disk... Men - det har fungerat
intill nu.
Vad jag gjorde var att ändra enhetsbeteckning på den i diskhanteraren,
eftersom jag behövde stoppa i en hårddisk från en annan dator på dess plats.
Följdaktligen fick den flytta från F: till W:, vilket fungerade finfint. Den
sågs och kunde användas som W:. Efter kopiering av filer från den tillfälliga
F: till W: stängde jag av datorn, kopplade ur den tillfälliga gästhårddisken
och startade windows igen. Ingen F:, W: fanns kvar och fungerade. Bytte
enhetsbeteckning från W: tillbaks till F: och då helt plötsligt hade den
inget filsystem! Iegenskaper var storleken 0 och filsystemet RAW. Kan det ha
blivit någon förvirring i systemet med CD-enheterna? Vill minnas att obrända
CD-skivor visas
med det formatet?
Betr. Ditt åtgärdsförslag: Hur ta bort den i BIOS utan att plugga ur den?
Eller skall den vara urpluggad till Windows är igång och sedan anslutas med
systemet igång??
Johan
Olof Lagerkvist
> Disken sitter på ett extra controllerkort (Promise Ultra 133 TX2) eftersom
> det är IDE-disk nr 4 i burken. Den har inte flyttats på fysiskt. Konstigt
> nog: i BIOS identifieras den som en SCSI-disk... Men - det har fungerat
> intill nu.
Ok, jag uppfattade som att du hade flyttat disken fysiskt. Att byta
enhetsbeteckning ska inte påverka filsystemet alls så det är något helt
annat som har hänt. Prova reparationsverktyg för filsystem som andra har
föreslagit.
> [...] Bytte
> enhetsbeteckning från W: tillbaks till F: och då helt plötsligt hade den
> inget filsystem! Iegenskaper var storleken 0 och filsystemet RAW. Kan det ha
> blivit någon förvirring i systemet med CD-enheterna? Vill minnas att obrända
> CD-skivor visas
> med det formatet?
Nej inte sammablandning med CD, CD-enheter är annorlunda och använder
andra filsystem än hårddiskpartitioner. Om inte disken visas som
CD-enhet i enhetshanteraren eller nåt annat knepigt så är det ingen fara.
> Betr. Ditt åtgärdsförslag: Hur ta bort den i BIOS utan att plugga ur den?
> Eller skall den vara urpluggad till Windows är igång och sedan anslutas med
> systemet igång??
Glöm vad jag skrev, det är inte intressant i ditt fall.
torbjorn.ekstrom
> Sun, 11 Jun 2006 21:10:15 GMT, Johan Plane ba:
>
>
>>Efter att ha arrangerat om hårddiskar i datorn påstår den att
>>filsystemet på en av mina hårddiskar är väck - anger att formatet är
>>RAW. Vid avstängningen var det NTFS.
>
>
>>Det är inte min bootdisk, så det problemet har jag inte, men det är min
>>största hårddisk och det skulle vara trist om allt gick förlorat.
>
>
>>Finns det något sätt att reparera den så att windows kan identifiera
>>NTFS igen utan att formattera om den?
>
>
> Du skulle kunna pröva DFSee. Det har räddat en partition åt mig som
> var totalt förlorad (Partition Magic gick in i en oändlig loop när
> jag flyttade en 16GB-partition 4GB OJMR). Med DFSee gick det att
> få ordning på partitionen och rädda majoriteten av filerna på den.
> (Det var inte NTFS utan HPFS).
>
> Nackdelen med ett så potent program som DFSee är att man måste läsa
> på _mycket_ noga innan man använder. Träna gärna på någon ersättlig
> partition (det går att göra 'undo' i många lägen, men det är dumt
> att förlita sig på att det ska fungera när man verkligen behöver
> det.
Åter igen - vid viktig/oersättlig data - gör en diskimage med kopiering
sektor för sektor till en annan (lika eller större) HD innan ev.
räddningsexpriment.
- rota aldrig på 'orginalet' utan att ha en backup-image som kan
återställa disken i det skick det var innan man använde de olika
räddningsprogrammen.
extern IDE-disk och firewire/USB-kabinett är mycket användbart i
sådanahär sammanhang och både USB och firewire/1394 emuleras nästan
alltid som SCSI-disk i Linux (och troligen också i windows)
Sektor för sektor kopieringen kan göras enkelt tex. med 'dd' i linux och
i det här läget bryr man sig inte om eventuella hårddiskgeometrier, utan
räknar och kopierar från sektor 0 tills det tar stop. (SCSI adresserar
sektorer denna väg och vet inte ens vad diskgeometrier är för något)
Förmodligen kan en modern linux också mounta en NTFS-partitionen och
läsa i den även om diskgeometrierna skulle vara felsatta - observera
Linux kan bara _läsa_ - inte skriva i NTFS-partitionen, och på på den
vägen kopiera ut och rädda värdefull data.
---
Alternativt någon ghostdisk-program i Windows (men jag skulle ändå ta
kopia med linux 'dd' också, tills windows ghostdisk-program verkligen
bevisat sitt värde och käns pålitlig) - torrkör och träna
handgreppen/komandona på ofarlig data om du är obekant/osäker med de
nya programmen/OS-miljöerna innan du ger dig på disk/data där en förlust
gör riktigt, riktigt ont..
>
> Ladda hem utvärderingsversionen (en diskettimage) från
>
> http://www.dfsee.com/dfsee
>
Men gör ovanstående sektor för sektor-kopiering först!!!
>
> Charlie.
Charlie R
> Åter igen - vid viktig/oersättlig data - gör en diskimage med kopiering
> sektor för sektor till en annan (lika eller större) HD innan ev.
> räddningsexpriment.
> - rota aldrig på 'orginalet' utan att ha en backup-image som kan
> återställa disken i det skick det var innan man använde de olika
> räddningsprogrammen.
Man bör nog göra skillnad på MBR och resten av disken här. Vad DFSee
frågar efter allra först är att få göra en kopia an MBR.
Felsymptomen som OP har beskrivit låter som någon form av partitions-
tabellkaos. och för att reda ut sådant behöver man inte skriva
någon annanstans än i MBR, där partitonstabellen ligger. Skulle
kan inte lyckas åstadkomma en vettig partitionstabell går det alltid
att lägga tillbaks den uppbackade (som ligger på DFSee-disketten).
Man bör förstås alltid backa upp disken man håller på med, men i det
fall den redan är hårdvarumässigt trasig (vilket händer rätt ofta
nuförtiden) är det nästan alltid för sent, så i efterhand gör det
i det fallet detsamma.
Om man har storre mängder oersättliga data är det bästa förstås att
köpa en extra disk från början och köra vinum eller någon annan form
av RAID.
Olof Lagerkvist
> Åter igen - vid viktig/oersättlig data - gör en diskimage med kopiering
> sektor för sektor till en annan (lika eller större) HD innan ev.
> räddningsexpriment.
Bra Torbjörn, detta är alltid värt att påpeka!
> - rota aldrig på 'orginalet' utan att ha en backup-image som kan
> återställa disken i det skick det var innan man använde de olika
> räddningsprogrammen.
> extern IDE-disk och firewire/USB-kabinett är mycket användbart i
> sådanahär sammanhang och både USB och firewire/1394 emuleras nästan
> alltid som SCSI-disk i Linux (och troligen också i windows)
>
> Sektor för sektor kopieringen kan göras enkelt tex. med 'dd' i linux och
> i det här läget bryr man sig inte om eventuella hårddiskgeometrier, utan
> räknar och kopierar från sektor 0 tills det tar stop. (SCSI adresserar
> sektorer denna väg och vet inte ens vad diskgeometrier är för något)
Moderna ATA-controllers använder ju LBA som är har ungefär samma
adresseringslogik. Problemet är dock som alltid det där med att få BIOS
att upptäcka disken och adressera den på ett tillräckligt kompatibelt
sätt för att sedan få igång operativsystemet. I det läget kan det uppstå
skillnader i hur olika BIOS (om man flyttar disken mellan olika
controllers) emulerar C/H/S-värden och ett operativsystem som försöker
anpassa sin syn på disken till hur BIOS upptäckte den för att inte få
problem med att disken ser olika stor ut för BIOS och operativsystemet
och liknande otrevliga fenomen...
Men det verkar trots allt inte alls röra sig om något problem med detta
i den här tråden utan något helt annat filsystemshaveri av någon märklig
anledning. Kanske trasig hårddiskcontroller eller trasig disk.
Men en image av diskvolymen är inte fel att ha ändå. Vill man inte
behöva starta Linux så kan man använda mitt 'rawcopy' i Windows
istället, t ex:
rawcopy \\.\F: C:\diskimage
http://here.is/olof/w32apps.htm
http://here.is/olof/files/rawcopy.zip
Det finns också Win32-ports av 'dd' i t ex paketet UnxUtils, i det fallet:
dd if=\\.\F: of=C:\diskimage
Men den är lite farlig eftersom den inte avmonterar och låser eventuellt
monterat filsystem först och inte heller ens varnar om någon annan
försöker skriva till volymen samtidigt. Rawcopy kräver åtminstone att
man använder en speciell flagga för att kringgå detta.
En diskimagefil kan man sedan montera som en virtuell disk med t ex min
drivrutin imdisk som också finns på http://here.is/olof/w32apps.htm en
bit ner.
torbjorn.ekstrom
>
> Moderna ATA-controllers använder ju LBA som är har ungefär samma
> adresseringslogik. Problemet är dock som alltid det där med att få BIOS
> att upptäcka disken och adressera den på ett tillräckligt kompatibelt
> sätt för att sedan få igång operativsystemet. I det läget kan det uppstå
> skillnader i hur olika BIOS (om man flyttar disken mellan olika
> controllers) emulerar C/H/S-värden och ett operativsystem som försöker
> anpassa sin syn på disken till hur BIOS upptäckte den för att inte få
> problem med att disken ser olika stor ut för BIOS och operativsystemet
> och liknande otrevliga fenomen...
om jag mins rätt så har alla IDE/ATA-diskar en subset av SCSI-kommandon
implementerade och kan adresseras på 'SCSI'-vis
därför är det väldigt lätt att i både Linux och Windows hantera/emulera
IDE/ATA-diskar som just logiskt sett SCSI-enheter om man bestämmer sig
för detta.
mao. diskhanteringen är enkel för OS:t när den väl har beslutat att
använda ATA/IDE-disken som just SCSI-disk.
Däremot iom. all viktig info i uppstartläget beskriven som CHS-notation
(MBR/många filsystemshuvuden etc.) och vad jag har förstått så är det
ingen lek när OS:t i början skall översätta given CHS-angivelse och ta
hänsyn till alla olika BIOS-generationers hantering av CHS-översättning
så att både CHS-notationen och motsvarande SCSI-adress pekar på samma
sektor i slutändan - där gäller det att hålla tungar rätt i mun...
Det är ungefär som att gammal DOS/Windows räknar med romerska siffror
medans moderna OS-versioner använder decimalsystemet - men precis som
filmindustrin fortfarande envisas med att ange inspelningsåret i
romerska siffror även i modern tid så bootas datorerna och volymerna
deklareras med den gamla notationen.
>
> Men det verkar trots allt inte alls röra sig om något problem med detta
> i den här tråden utan något helt annat filsystemshaveri av någon märklig
> anledning. Kanske trasig hårddiskcontroller eller trasig disk.
>
jo, hade samma tanke - har man lässvårigheter när man kopierar sektor
för sektor till annan disk så kan man ana en av orsaken till
problemen... - då får man vara glad över alla sektorer man trots allt
lyckas få över till backup-HD:n.
är det viktig data så bör man avbryta (stäng av disken snabbt) och
anlita proffessionell hjälp typ IBAS. - varje sekund onödig gångtid här
är viktig om man kommer att lyckas rädda datat eller inte.
---
har man misstänkt filsystemshaveri, så bör man absolut göra diskimage
innan man låter windows försöka reparera systemet - misslyckas windows
med reparationen så är situationen ännu värre än innan och kanske
olösligt nu, oavsett hur mycket räddningsprogram man än använder - det
är då det är bra med den ursprungliga diskimage-kopian och efter
tillbakakopiering så kan man prova igen med ny räddningsstrategi.
Man kan även prova att i Linux mounta NTFS - iom. att dess läsning är
reverse-enginerad så är den kanske inte lika grinig och noggrann som
orginal windows-avläsning - som tex ignorera ev. rättightesstrul och
läser allt ändå. Att använda Linux för att läsa NTFS var ju ganska känd
bakväg redan på NT 3.51-tiden när man hade av någon anledning utlåsta
serverhårddiskar (dock ej krypterade) och man ville rädda data (alt.
knäcka och byta password i systemet)
> Men en image av diskvolymen är inte fel att ha ändå. Vill man inte
> behöva starta Linux så kan man använda mitt 'rawcopy' i Windows
> istället, t ex:
>
> rawcopy \\.\F: C:\diskimage
>
> http://here.is/olof/w32apps.htm
> http://here.is/olof/files/rawcopy.zip
>
> Det finns också Win32-ports av 'dd' i t ex paketet UnxUtils, i det fallet:
>
> dd if=\\.\F: of=C:\diskimage
< knippe mycket bra vertyg - synd att man aldrig vet om eller hittar
dessa när man väl behöver dom i windows>
intressant - jag har alltid undrat hur man adresserar/namnger enheter
där man kan läsa i rå-format i windows på samma sätt som Linux
/dev/xxx-referenser.
Är ovanstående specifikt för din program eller är det allmän
adresserings-konvention för att läsa och skriva i rå-format på
windows-device???
vidare:
en kort fråga - hur omvandlar man en mountad live-disk i windows till
en som är satt read/only för typ ovanstående image-kopieringsövningar??
I linux kan man köra allt i RO (vilket den också gör i uppstartsfasen
med filsystem-check) och sedan växla till RW, och har för mig inte var
så svårt att ställa i RO igen för just sådanahär kinkiga operationer.
>
> Men den är lite farlig eftersom den inte avmonterar och låser eventuellt
> monterat filsystem först och inte heller ens varnar om någon annan
> försöker skriva till volymen samtidigt. Rawcopy kräver åtminstone att
> man använder en speciell flagga för att kringgå detta.
>
> En diskimagefil kan man sedan montera som en virtuell disk med t ex min
> drivrutin imdisk som också finns på http://here.is/olof/w32apps.htm en
> bit ner.
>
tackar - sidan sparad, sådant här lågnivå-mixter är ganska enkel att
göra i Linux/Unix - men traditionellt svårt att göra i Windows utan
avsedda och ofta kommersiella produkter för detta.
/TE
Olof Lagerkvist
> om jag mins rätt så har alla IDE/ATA-diskar en subset av SCSI-kommandon
> implementerade och kan adresseras på 'SCSI'-vis
>
> därför är det väldigt lätt att i både Linux och Windows hantera/emulera
> IDE/ATA-diskar som just logiskt sett SCSI-enheter om man bestämmer sig
> för detta.
>
> mao. diskhanteringen är enkel för OS:t när den väl har beslutat att
> använda ATA/IDE-disken som just SCSI-disk.
Japp. LBA - Logical Block Addressing. Specifikationen har utökats något
under sin livslängd för att täcka in större diskar.
> Däremot iom. all viktig info i uppstartläget beskriven som CHS-notation
> (MBR/många filsystemshuvuden etc.) och vad jag har förstått så är det
> ingen lek när OS:t i början skall översätta given CHS-angivelse och ta
> hänsyn till alla olika BIOS-generationers hantering av CHS-översättning
> så att både CHS-notationen och motsvarande SCSI-adress pekar på samma
> sektor i slutändan - där gäller det att hålla tungar rätt i mun...
Ja, och här kan man råka ut för alla möjliga tänkbara lustigheter när
man flyttar diskar mellan olika generationers controllers och olika
BIOS. Många gånger hjälper det dock att få igång en trilskande
Windows-installation (om det är BIOS som vägrar starta bootloadern)
genom att starta på en diskett med enbart Windows bootloader, dvs ntldr
och ntdetect.com, och en boot.ini som pekar på rätt katalog på
hårddisken så kommer det igång ändå.
> Det är ungefär som att gammal DOS/Windows räknar med romerska siffror
> medans moderna OS-versioner använder decimalsystemet - men precis som
> filmindustrin fortfarande envisas med att ange inspelningsåret i
> romerska siffror även i modern tid så bootas datorerna och volymerna
> deklareras med den gamla notationen.
Kul jämförelse, men det är ungefär så det är. Det intressanta är ju
alltså att det egentligen inte sedan MFM-tiden har varit intressant med
C/H/S-värden för PC-diskar öht, men eftersom man fastnade redan då i att
BIOS skulle prata C/H/S så är det så än idag...
> < knippe mycket bra vertyg - synd att man aldrig vet om eller hittar
> dessa när man väl behöver dom i windows>
>
> intressant - jag har alltid undrat hur man adresserar/namnger enheter
> där man kan läsa i rå-format i windows på samma sätt som Linux
> /dev/xxx-referenser.
> Är ovanstående specifikt för din program eller är det allmän
> adresserings-konvention för att läsa och skriva i rå-format på
> windows-device???
Det är inget specifikt utan det är så det fungerar i Windows.
Det här är egentligen en djungel och tar ett antar års erfarenhet innan
man begriper hur allt det här hänger ihop tyvärr. Men jag kan ge mig på
en liten förklaring nu när vi ändå är inne på ämnet. Det är annars till
viss del dokumenterat här:
http://msdn.microsoft.com/library/en-us/fileio/fs/createfile.asp
De allra flesta program körs i Win32 subsystem och dessa program
använder inte Windows-kärnans egentliga system för sökvägar utan
emulerar en MS-DOS-liknande logik med enhetsbokstäver och liknande.
Bakom kulisserna går det till så att alla dessa "DOS-sökvägar" översätts
till kärnkompatibla sökvägar genom att utgå från katalogen \DosDevices.
Under den katalogen finns t ex oftast en symbolisk länk som heter C: och
som pekar på \Device\Harddisk0\Partition1 så att Win32-programmet som
efterfrågar C:\Katalog\min_fil.txt i själva verket ska öppna
\DosDevices\C:\Katalog\min_fil.txt som efter symlänk-översättning sedan
blir \Device\Harddisk0\Partition1\Katalog\min_fil.txt så att kärnan och
drivrutinerna ska förstå vad som önskas.
Om man ska komma åt volymen för direktåtkomst så behöver man alltså
öppna \Device\Harddisk0\Partition1 vilket man borde kunna göra med
enbart C: men det går inte eftersom "DOS-logiken" säger att "C:" ska
motsvara "processens aktuella katalog på enhet C:" vilket alltså
översätts till en katalog under den volymen, inte själva volymen. Samma
problem finns om man ska skapa en fil som heter COM1. Var än sådana namn
dyker upp blir översättningen \DosDevices\COM1 som pekar på
\Device\Serial0 och inte någon fil...
Så för att fortfarande hålla kvar vid "DOS-semantiken" och ändå lösa
detta bekymmer införde NT-makarna en speciell notation med \\.\ eller
\\?\ före sökvägar. Använder man någon av dessa sökvägar hakas den
efterföljande strängen direkt på \DosDevices\ och skickas till kärnan
utan vidare funderingar över aktuella kataloger eller speciella filnamn
som ska motsvara serieportar. Alltså kan man använda \\.\C: eller \\?\C:
när man ska komma åt \DosDevices\C: för \Device\Harddisk0\Partition1
eller vilken volym det nu är som heter C:, på samma sätt som man kan
använda \\.\C:\COM1 för att skapa en fil under C:\ som heter COM1
istället för att öppna första serieporten...
Ok, det är väl bra tänker man nu, men om vi nu vill läsa _hela
hårddisken_ direkt, inte någon speciell partition, hur gör man då? Jo,
man öppnar \Device\Harddisk0\Partition0. Ok, men hur kommer man åt den,
det finns ju ingen enhetsbeteckning som motsvarar hela disken? Jo, det
gör det. Men inte många vet om det. Men svaret är att PhysicalDrive0
motsvarar \Device\Harddisk0\Partition0, PhysicalDrive1 motsvarar
\Device\Harddisk1\Partition0 osv, alltså går det att använda:
rawcopy \\.\PhysicalDrive0 disk_image_fil
för att ta en kopia på hela disken, inklusive partitionstabellen och
liknande.
För att se katalogen \Device och liknande behöver man ett verktyg som
pratar med "native API" direkt mot kärnan. Ex SysInternals WinObj:
http://www.sysinternals.com/Utilities/WinObj.html
> en kort fråga - hur omvandlar man en mountad live-disk i windows till
> en som är satt read/only för typ ovanstående image-kopieringsövningar??
Man låser den (så att ingen annan process kan komma åt den) och
avmonterar den (så att filsystemsdrivrutinen släpper den). Detta görs
med FSCTL-kommandon direkt till filsystemsdrivrutinen av programmet som
behöver direkt tillgång till volymen.
http://msdn.microsoft.com/library/en-us/fileio/fs/volume_management_control_codes.asp
Det här gör t ex inte den Win32-port av 'dd' som finns med i UnxUtils
tyvärr, däremot har jag lagt in den funktionen i 'rawcopy'.
> I linux kan man köra allt i RO (vilket den också gör i uppstartsfasen
> med filsystem-check) och sedan växla till RW, och har för mig inte var
> så svårt att ställa i RO igen för just sådanahär kinkiga operationer.
Det finns inget bra sätt att montera ett filsystem i read-only-läge. Det
finns dock några mindre bra, t ex att lägga en filterdrivrutin ovanpå
diskdrivrutinen och låta denna rapportera att volymen är "read-only" när
filsystemet under monteringsoperationen frågar diskdrivrutinen om
volymen är skrivbar (detta är egentligen inte så hemskt komplicerat),
eller en ännu mindre bra lösning att lägga ett filsystemsfilter som
filtrerar bort och nekar skrivoperationer från applikationerna.
> tackar - sidan sparad, sådant här lågnivå-mixter är ganska enkel att
> göra i Linux/Unix - men traditionellt svårt att göra i Windows utan
> avsedda och ofta kommersiella produkter för detta.
Sant, men det har dock dykt upp ganska många sådana projekt för Windows
också sista åren, ta t ex alla dessa
ext2/3-reiser-ufs-filsystemsdrivrutiner som dyker upp för Windows överallt.
Kan också nämna att mitt ImDisk också kan användas över nätverk så att
man kan montera en volym på t ex en havererad Windows-maskin från en
annan frisk Windows-maskin över nätverk, t ex starta på en
Linux/Unix-live-CD och köra en liten serverdel mot en volym på datorn
som ImDisk på en frisk Windows-maskin kan komma åt och låta
filsystemsdrivrutinen där montera. Man kan alltså t ex köra chkdsk på en
volym som fysiskt finns på en annan dator där man inte får igång Windows
alls. Det här har jag haft nytta av för många räddningsprojekt. Att t ex
kunna montera registerdatabaserna på en havererad Windows-installation
från en annan Windows-dator är t ex väldigt intressant i många sammanhang.
Johan Plane
Jaha kära vänner,
Det är inget fel på hårddisken i sig - alla filer finns kvar i sina resp. bibliotek. I
alla fall efter vad jag fått fram efter att ha kört DFSee. Det verkar bara vara MBR som
muppat till sig. Återstår bara att skaffa en lika stor hårddisk och få över allt till
den. Attans att man inte kan reparera MBR på den befintliga HDD'n.
Johan
Charlie R
> Det är inget fel på hårddisken i sig - alla filer finns kvar i sina resp. bibliotek. I
> alla fall efter vad jag fått fram efter att ha kört DFSee. Det verkar bara vara MBR som
> muppat till sig.
Detär ju ändå inte så illa.
> Återstår bara att skaffa en lika stor hårddisk och få över allt till
> den.
Du behöver inte ha en exakt lika stor hårddisk; det räcker med en som
rymmer en avbildning av originalet.
> Attans att man inte kan reparera MBR på den befintliga HDD'n.
Visst kan du det. Det är bara om du vill vara 100-procentigt säker
på ha kvar alla data på disken som du måste backa upp den.
Räcker det med 99-procentig säkerhet kan du reparera MBR med DFSee(*);
gör sedan 'chkdsk' på den restaurerade partitionen. bara Se till att
du inte skriver på den innan du övertygat dig om att du har
kvar alla filer och kan läsa dem.Jag vet inte om det går att montera
partitioner "read-only" med Windows; gör det det är det förstås att
rekommendera.
* Övertyga dig först om att du har en backup av den trasiga MBR-en.
Charlie.
--
Hurewitz's Memory Principle:
The chance of forgetting something is directly proportional
to ..... to ........ uh ..............