Date: Tue, 5 Oct 2010 03:53:09 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Robert Bonomi <bonomi@mail.r-bonomi.com> Cc: freebsd-questions@freebsd.org, traveling08@cox.net Subject: Re: OT: fdisk Message-ID: <20101005020924.H59829@sola.nimnet.asn.au> In-Reply-To: <20101004120028.1860F10657D0@hub.freebsd.org> References: <20101004120028.1860F10657D0@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In freebsd-questions Digest, Vol 331, Issue 1, Message: 5 On Sun, 3 Oct 2010 08:19:36 -0500 (CDT) Robert Bonomi <bonomi@mail.r-bonomi.com> wrote: > > On Sat, 2 Oct 2010 17:00:00 -0600 (MDT) > > Warren Block <wblock@wonkity.com> wrote: > > > > > On Sat, 2 Oct 2010, Robert wrote: > > > > > > > Greetings > > > > > > > > I am in deep with the wife. Her computer went belly up. It was > > > > running XP pro and I had backups going to a second drive. I can no > > > > longer access that drive. > > > > > > > > I pulled it and attached it via USB to one of my FreeBSD machines > > > > but it will not mount. It is a 500G hard drive and I get _wild_ > > > > results just looking at it with fdisk. > > > > > > > > ~> fdisk /dev/da1s1 > > > > ******* Working on device /dev/da1s1 ******* > > > > > > Wait a minute... shouldn't that be just "da1"? da1s1 is the first > > > slice (partition), and the data there should be your XP filesystem, > > > probably NTFS. > > > > Warren, > > > > You are right. Here it is: > > > > ~> fdisk /dev/da1 > > ******* Working on device /dev/da1 ******* > > parameters extracted from in-core disklabel are: > > cylinders=60801 heads=255 sectors/track=63 (16065 blks/cyl) > > > > Figures below won't work with BIOS for partitions not in cyl 1 > > parameters to be used for BIOS calculations are: > > cylinders=60801 heads=255 sectors/track=63 (16065 blks/cyl) > > > > Media sector size is 512 > > Warning: BIOS sector numbering starts with sector 1 > > Information from DOS bootblock is: > > The data for partition 1 is: > > sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX) > > start 63, size 976773105 (476939 Meg), flag 0 > > beg: cyl 0/ head 1/ sector 1; > > end: cyl 1023/ head 15/ sector 63 > > The data for partition 2 is: > > <UNUSED> > > The data for partition 3 is: > > <UNUSED> > > The data for partition 4 is: > > <UNUSED> Robert Bonomi, replying to yours before the above slipped away, but I'm directing this to Robert the OP, ok? So pausing here for a bit .. starting at 63 (cyl 0/ head 1/ sector1 in CHS terms), looks correct for s1, one slice, whole disk for NTFS. That should rule out a damaged MBR in sector 0 - though it doesn't rule out the boot code in the first 2 or so sectors having been clobbered. You can often poke around the beginning of disks to advantage with say: # dd if=/dev/da1 bs=512 count=126 | hd | less to see the first two tracks .. sector 63 should be where NTFS starts, ie after sectors 0-62 on head 0. hd(1) skips repeated zeroes or 0xff and such, so you can hunt through quite a lot of early sectors without huge output in less, usually. > > Which looks a lot better. I can mount /dev/da1 and it shows Just to be clear, you mean: '# mount_ntfs /dev/da1 /mnt' ? (try to be sure to mount NTFS filesystems _explicitly_ read-only, especially if likely damaged) > > ~> ls -l /mnt > > total 70044 > > -rwxr-xr-x 1 root wheel 2560 Dec 31 1600 $AttrDef > > -rwxr-xr-x 1 root wheel 0 Oct 1 09:09 $BadClus > > -rwxr-xr-x 1 root wheel 4194304 Dec 31 1600 $Bitmap > > -rwxr-xr-x 1 root wheel 8192 Oct 1 09:09 $Boot > > drwxr-xr-x 1 root wheel 0 Oct 1 09:09 $Extend > > -rwxr-xr-x 1 root wheel 67108864 Oct 1 09:09 $LogFile > > -rwxr-xr-x 1 root wheel 4096 Oct 1 09:09 $MFTMirr > > -rwxr-xr-x 1 root wheel 0 Dec 31 1600 $Secure > > -rwxr-xr-x 1 root wheel 131072 Oct 1 09:09 $UpCase > > -rwxr-xr-x 1 root wheel 0 Oct 1 09:09 $Volume > > -rwxr-xr-x 1 root wheel 45124 Aug 18 2001 NTDETECT.COM > > drwxr-xr-x 1 root wheel 0 Oct 1 17:29 System Volume > > Information > > -rwxr-xr-x 1 root wheel 193 Oct 1 09:12 boot.ini > > -rwxr-xr-x 1 root wheel 222368 Aug 18 2001 ntldr > > > > But I cannot mount /dev/da1s1 > > > > ~> sudo mount_ntfs /dev/da1s1 /mnt > > mount_ntfs: /dev/da1s1: Invalid argument Ok, and its not clear why/how mount_ntfs would be happy mounting da1 'raw' but it sure looks like (at least part of) an NTFS root directory; not necessarily all what you'd see as C:\ in windows explorer, say; windows plays strange tricks the way it layers directories for display. There's weird dates (1600?) and only you would know if those October 1st timestamps are of when you mounted it, or when windows last accessed it? The fact that boot.ini is a few minutes later than some is interesting; that's where entries for multi-booting NT may exist, and maybe something messed with that, hardware glitch? or (not entirely unknown :) one of a hundred thousand or so viruses? So, can you look at these files when so mounted? Can you do something like 'du -d2 /mnt' and see anything useful? I'm just guessing /hoping here that the disk may not be as badly scrambled as you fear, despite the apparent oddness of it mounting like that. >From a later message, quoting Robert: > Warren, thanks for the link. I will be reading it and increasing my > understanding of NTFS. Though it's an old (pre-XP) article, it's good basics. Note especially that NTFS keeps a copy somewhere near the middle of the disk of primary metadata, and that your ls above shows what's listed there, eg $MFTMirr which presumably points to that metadata 'mirror' somehow. > I do not think there is anything physically wrong with the disk. I > just cannot reach the data on it. Using "photorec" I have all files > moved to a spare slice on this FreesBSD machine. It appears that there > is less than 60G of actual data on the drive. Most of it is not needed > so it will take quite awhile to sort the wanted from the unwanted. > > I have a spare 250G hard drive. Can I use "dd" to capture 250 gigs There's no guarantee at all - even if the filesystem had just been defragged in windows - that there won't be bits of data all over the disk. Having to back up an entire 500G drive is a pain .. even in windows multiple slices / partitions make sense, eh? - but I don't know how you determined that only 60GB was in use, or that you got all the filesystem metadata as well as what you determined as used? > This drive was used for a backup of of the Docs&Sets "folders" of the > XP drive. It also had music and photo files that are also on the > FreeBSD computer so they are not that critical. The Docs&Sets folders > are the most important to recover so if I can access the data, I can > burn it to DVD. Well if you can descend into anything beyond the root directory you got access to above mounting da1 (read-only hopefully!), you may be in luck. D&S lives quite deep in the tree on windows (ie under the per-user level) but you'd have to hunt the path from the root to there on maybe another windows box. You may or may not have damaged directories above. You've received lots of great advice about tools to use _after_ you've secured a full backup (for which dd is great), but in this case I can't help suspecting the best tools to salvage / repair a winXP NTFS disk are most likely found in windows land, probably bewilderingly plentiful :) Put another way .. FreeBSD's NTFS (native or the fuse ports) may or may not be up to read/write safely by now for normal use, but I'm not sure they'd likely be up to what windows chkdsk / scandisk can do in the way of filesystem repair, let alone some of the better third-party tools. Hope that at least doesn't hinder :) cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101005020924.H59829>