# [solved] Cannot open/copy a 50.0 mb file on USB memory.

## optiluca

Hi.  Today I transferred a whole load of photos/videos from my FAT formatted camera to my laptop, and everything went just fine, except for the largest file present, at 50.0 mb.  This file refused to copy under dolphin so I tried in a console and got

```
cp -v /media/disk/DCIM/100_PANA/P1000837.MOV /home/luca/

`/media/disk/DCIM/100_PANA/P1000837.MOV' -> `/home/luca/P1000837.MOV'

cp: reading `/media/disk/DCIM/100_PANA/P1000837.MOV': Input/output error
```

And the following error appeared in dmesg

```
[ 8365.456896] attempt to access beyond end of device

[ 8365.456903] sdb1: rw=0, want=7736320, limit=7736319

[ 8365.457222] attempt to access beyond end of device

[ 8365.457226] sdb1: rw=0, want=7736320, limit=7736319
```

All smaller files worked just fine..   :Confused:   Any ideas?

Thanks in advance  :Smile: 

----------

## deathcon1

You're trying to read from an address past the end of the partition.  

Post the output of

```
fdisk -l <PATH TO MEMORY CARD>
```

----------

## optiluca

 *deathcon1 wrote:*   

> You're trying to read from an address past the end of the partition.  
> 
> Post the output of
> 
> ```
> ...

 

This is not the last video/picture i took though, and all the following ones were just fine   :Confused: 

Anyway..

```
fdisk -l /dev/sdb

Disk /dev/sdb: 3965 MB, 3965189632 bytes

49 heads, 48 sectors/track, 3292 cylinders

Units = cylinders of 2352 * 512 = 1204224 bytes

Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System

/dev/sdb1               4        3293     3868160    b  W95 FAT32

```

BTW, in case it helps..

 *Quote:*   

>  emerge --info
> 
> Portage 2.2_rc33 (default/linux/amd64/2008.0/desktop, gcc-4.3.3, glibc-2.10.1-r0, 2.6.30-gentoo-r1 x86_64)
> 
> =================================================================                                         
> ...

 

----------

## Peach

it could be an issue with the FAT tables, these things happens (crappy vfat)

but I could be wrong. 

I'd suggest to dump the USB disk to a file with dd 

then try to mount it, see if the error is still there and then try touse fsck.vfat from the dosfstools to check the fs.

Hope someone's something else to say about it   :Confused: 

----------

## eccerr0r

 *optiluca wrote:*   

> 
> 
> ```
> fdisk -l /dev/sdb
> 
> ...

 

Oops, 3292 cylinders and end at 3293?

Can the device that wrote the card read the file back, itself?

----------

## deathcon1

I think Peach is right - something's probably corrupted.  Use DD to get an image of the drive then run the FAT file system check on the drive and try again.  This way if the file system check blows up you can still extract the images from the dd file.  

```
dd if=/dev/[USB DRIVE] of=~/usb_image.dd
```

Make sure you get the entire drive, not just a partition.  I.E. if the drive is located at /dev/sdb1 run it on /dev/sdb so you don't capture just one partition. 

Ok, now that you have the image, proceed with the file system check then try copying off the drive.  [/code]

----------

## optiluca

Ok so I made the image of the memory card, but fsck.vfat run as root user is throwing interesting errors at me...

```
fsck.vfat -av /dev/sdb1

dosfsck 3.0.2 (28 Feb 2009)

dosfsck 3.0.2, 28 Feb 2009, FAT32, LFN

open /dev/sdb:Read-only file system
```

```
fsck.vfat -v /dev/sdb1       

dosfsck 3.0.2 (28 Feb 2009)                                

dosfsck 3.0.2, 28 Feb 2009, FAT32, LFN                     

Checking we can access the last sector of the filesystem   

Boot sector contents:                                      

System ID "        "                                       

Media byte 0xf8 (hard disk)                                

       512 bytes per logical sector                        

     32768 bytes per cluster                               

      6304 reserved sectors

First FAT starts at byte 3227648 (sector 6304)

         2 FATs, 32 bit entries

    483328 bytes per FAT (= 944 sectors)

Root directory start at cluster 2 (arbitrary size)

Data area starts at byte 4194304 (sector 8192)

    120752 data clusters (3956801536 bytes)

63 sectors/track, 128 heads

      8192 hidden sectors

   7736320 sectors total

Checking for unused clusters.

Checking free cluster summary.

Free cluster summary wrong (4294967295 vs. really 22390)

1) Correct

2) Don't correct

? 1

Leaving file system unchanged.

/dev/sdb1: 409 files, 98362/120752 clusters
```

And this is as root user??

Am I doing anything blatantly wrong?

Thanks to all  :Smile: 

----------

## Peach

I'd really suggest you to work on the image file, instead of the physical USB.

create the image:

```
# dd if=/dev/sdb of=/path/to/usb.img
```

(as deathcon1 already told you)

mount the image created with dd

```
# mount -o loop /path/to/usb.img /mnt/disk
```

then try to access the files and see if everything still's giving errors, if so, go on and start fsck.vfat on the img file, try to recover the errors and if everything is going ok, reformat the USB disk (maybe from inside the camera).

```
# fsck.vfat -v /path/to/usb.img
```

If instead you cannot recover the error we should try to find out what the error is.

I repeat, don't touch the physical disk: you can mess with the image, but at least you always have the source.

I wouldn't mind the RO flag on the mounted USB at this point.

I'll wait for your next post  :Smile:  keep going.

----------

## optiluca

```
mount -o loop /home/luca/usb_image.dd /mnt/disk/

mount: you must specify the filesystem type
```

 :Confused: 

Thanks for your prompt reply btw  :Smile: 

----------

## Peach

 *optiluca wrote:*   

> 
> 
> ```
> mount -o loop /home/luca/usb_image.dd /mnt/disk/
> 
> ...

 

you're right

since you dd the entire disk instead of the whole partition, you need to specify the offset for the partition to be mounted (infact you can only mount partitions with mount, and not "disks")

for this to work we need to calculate the offset for the partition

first use fdisk with -u to have a unit size of sectors (should be 512b unit) instead of cylinders:

for example:

```
# fdisk -lu /dev/sdb

Disco /dev/sdb: 8317 MB, 8317304832 byte

64 testine, 32 settori/tracce, 7932 cilindri, totale 16244736 settori

Unità = settori di 1 * 512 = 512 byte

Identificativo disco: 0x69737369

Dispositivo Boot      Start         End      Blocks   Id  System

/dev/sdb1              32    16244735     8122352    7  HPFS/NTFS
```

you should see where the start is (32) and multiply it by 512 (= 16384 bytes)

now you can mount it correctly with:

```
# mount -o loop,offset=16384 /path/to/img /mnt/disk
```

that's it

sorry if this might be a bit sophisticated, but that's the clean way.

 :Smile: 

----------

## optiluca

The copy works successfully from the image file  :Very Happy:   Thank you very much  :Smile:   Could you give me an explanation as to why the hell the file from the card doesn't work and the same file on what should be a perfect copy of the card does??  In any case, should I expect this to happen again?   :Confused: 

Grazie mille  :Smile: 

----------

## Peach

 *optiluca wrote:*   

> The copy works successfully from the image file   Thank you very much   Could you give me an explanation as to why the hell the file from the card doesn't work and the same file on what should be a perfect copy of the card does??  In any case, should I expect this to happen again?   

 

That's great. 

Why? Nice question. VFAT filesystems are a bad beast (read: "shortname" default option hell, no atime and ctime, no real perms, and so on), so actually the problem could lie on a a bad partition descriptor, or even on a bad FAT table entry, but I'm not that sure about the latter.

I don't think the problem could lie on the hardware, since you could have had problems even reading with dd.

Anyway I strongly suggest you to re-format carefully the disk to avoid any future errors on it.

 *optiluca wrote:*   

> Grazie mille 

 

Figurati  :Wink: 

----------

