Wife's USB HDD has a slight issue where a folder refuses to open (NTFS filesystem). I have been able to image the drive with Linux but for one sector (sectors are 4096 bytes). Reading that sector fails:

sudo dd if=/dev/sdb of=block skip=21647245 bs=4096 count=1
dd: error reading ‘/dev/sdb’: Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 22.9317 s, 0.0 kB/s

Replacing this sector with null bytes leads to the same symptom as in Windows, so the sector seems to be related to the problematic directory.

When accessing said sector dmesg output reads:

[20381.842495] sd 7:0:0:0: [sdb] Unhandled sense code
[20381.842506] sd 7:0:0:0: [sdb]  
[20381.842510] Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[20381.842514] sd 7:0:0:0: [sdb]  
[20381.842517] Sense Key : Hardware Error [current] 
[20381.842531] sd 7:0:0:0: [sdb]  
[20381.842535] Add. Sense: No additional sense information
[20381.842539] sd 7:0:0:0: [sdb] CDB: 
[20381.842542] Read(10): 28 00 01 4a 4f 8d 00 00 01 00
[20381.842557] end_request: I/O error, dev sdb, sector 173177960
[20381.842572] Buffer I/O error on device sdb, logical block 21647245

Is there a way to read this sector, raw, without CRC checking or whatever to actually try to recover some of the corrupted data?

I opened the enclosure: the HDD is native USB, no USB to SATA conversion.

Edit: Tried ddrescue, but has not been able to recover the bad sector either. Reading 2Gigs around the bad sector the let the heads stabilize after the seek:

sudo ddrescue -s 2Gi -o 0 -i 87593373696 /dev/sdb blkk
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued:     2147 MB,  errsize:    4096 B,  current rate:        0 B/s
   ipos:    88667 MB,   errors:       1,    average rate:    8488 kB/s
   opos:     1073 MB, run time:    4.21 m,  successful read:    1.06 m ago

Reading backwards (-R flag) failed too.

Edit 2: My planned second step was to use forensics to try to get the missing files. I first started looking at the MFT by hand, but this quickly gets very, very tedious. So I had the following tools on my list:

  1. the Sleuthkit
  2. ntfs-3g
  3. scalpel
  4. scrounge-ntfs

The Sleuthkit would not do anything useful, quitting very early complaining about errors in metadata structures.

With Ntfs-3g (now Tuxera) it is possible to mount the image with debug output:

sudo mount -o loop,ro,offset=258048,debug image2 ./mnt -t ntfs-3g

Trying to enter the faulty directory would trigger an error:

Index buffer (VCN 0x0) of directory inode 101874 has a size (24) differing from the directory specified size (4096).

Looking for that error in DuckduckGo lead me to the following post: http://www.tuxera.com/forum/viewtopic.php?f=3&t=27054 It turns out that the people at Tuxera / ntfs-3g actually encourage the use of Microsoft's CHKDSK to recover NTFS errors

Running chkdsk on the disk was my third and last planned step, however it should be tried much earlier knowing that it CAN be run on a disk image, using for example OSFMount (http://www.osforensics.com/tools/mount-disk-images.html).

Most of the missing files and directories (if not all) have been recovered by chkdsk /f on the mounted disk image. More than a hundred errors (most of which being orphaned files) have been fixed.

Edit 3: I am accepting psusi's answer. Although not proved to be impossible, trying to read the bad sectors is certainly the most uncertain and difficult route for recovering data from a mildly damaged HDD.


No, it isn't possible. There is a SCSI command to do this, but you would still only be getting garbage, and it isn't supported on consumer level drives, especially not USB. Whatever was in that sector is gone.

  • It wouldn't necessarily be garbage. It might be otherwise good data with one bad bit which fails the CRC. A looong time ago, I could use the linux generic scsi driver and an associated utility to issue commands directly to the device (I did scsi-level driver programming 18 years ago). If there are such raw commands, it might be useful to try. – Otheus May 15 '15 at 2:46
  • This IS actually what I would like to do :) and decide by myself whether data read is total or only partial garbage ... – Balzola May 15 '15 at 12:05
  • @Otheus, nope, doesn't work that way. Before the CRC there is an ECC. Up to a certain number of bad bits, it corrects, but as soon as you go over that, it starts spitting out garbage. – psusi May 16 '15 at 18:27
  • @psusi ECC on disk media? You got a reference for that? – Otheus May 16 '15 at 18:29
  • @Otheus, en.wikipedia.org/wiki/Hard_disk_drive – psusi May 16 '15 at 18:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.