50

My hard drive crashed, so I'm using a Ubuntu live disk to access my files. But as I try to transfer them to my flash drive, it occasionally comes up with an error message which, when I view details, says:

Error splicing file: Input/output error.

How can I fix this?

Eric Carvalho
  • 54,385
Pistos
  • 501
  • 1
  • 4
  • 3

6 Answers6

65

The problem is because your destination disk (the disk to which you want to copy the file) is formatted with FAT32 (which has a file size limit of about 4GB. The solution is to format your destination disk to EXT3, EXT4, or NTFS (if you need windows compatibility).

Sisay Chala
  • 1,131
  • 25
    This is almost always incorrect. – Marc.2377 Jul 03 '17 at 00:03
  • 4
    Trying to copy from a Mac formatted USB to NTFS drive, and I'm getting this error. Need a better answer on this. – Shayan Mar 18 '18 at 18:05
  • 2
    This is nonsense. I get this error copying from a windows application CD to my EXT4 hard disk. I also get an error for the same file when I try to install the software on a windows machine, so it's nothing whatever to do with the destination disk type. – Peter Flynn May 28 '19 at 21:46
  • 3
    This (reformatting the drive to NTFS) worked for me when I was trying to create a Windows 10 USB boot drive. – GenesRus Oct 22 '19 at 03:31
  • if you are using USB formatted with default FAT32 this would be the problem – Alex Punnen Jan 08 '20 at 04:42
  • 1
    I just had this same problem, copying from an ext3 disk to an ext4 disk. There is clearly far more to this issue than this answer acknowledges. – Matthew Najmon Mar 18 '20 at 06:50
  • Who's upvoting this? It's clearly not correct. I'm getting this error copying from ExFAT USB SD card reader to Btrfs drive. There are no file size limitations. The SD being corrupt is the fundamental problem – endolith May 06 '20 at 06:11
  • 2
    Sure enough my USB 3.0 was formatted fat32 & formatting as ext4 fixed it. For those objecting, perhaps there is a similar error, or this same message is reused some other reason, but fat32 has a maximum fie size of 2^32 (hence the name) = 4294967296 bytes = 4Gb and isn't capable of 'tracking' the file data beyond that point. – Chaos7703 Sep 20 '20 at 17:08
  • I have to agree: this error occurs both ways ... either copying to FAT32 or from FAT32 (Windows) formatted disks to EXT3 or EXT4 (Linux). So the basic cause is incompatibility of formatting standards. – somethis Apr 12 '21 at 14:56
  • 1
    This fixed my issue with my NVME SSD that I formatted as FAT32. I was trying to copy a 42GB tarball to my SSD when I encountered this error Error splicing file: Input/output error.. – phagento Sep 05 '21 at 02:59
5

I would say that since the hard disk is failing, there is no way to solve the error. Depending on what is wrong with the hard disk, you may be able to try copying a file several times and maybe eventually get it correct. It would be advisable to move as quickly as possible and make sure to get your most important files first, because your hard disk may be getting worse and worse.

Sorry for the bad prognosis.

Richard
  • 8,502
  • 11
  • 47
  • 72
  • But in my case the error occurs no matter what the target disk is, so it's a problem with the source file on the CD, nothing to do with the target disk at all. – Peter Flynn May 28 '19 at 21:47
  • I had several splicing errors while copying from ext4 to a usb stick. And after that the usb stick was full of garbage which could not be deleted (read only errors). I had bought 2 usb sticks at the same time from the same place. The only difference was their colour. I tried the other one. No splicing errors, no garbage, everything fine. So in my case, it was a problem with the target disk. – Alain Reve Apr 27 '23 at 16:29
2

I feel this answer should be here for anyone who are experience failing disks.

The best way to approach a disk that is failing is to detach it carefully from power source and give it to the expensive guys. If you are impatient or feeling lucky, the next best thing is to create a copy of it on block level like this:

  1. Boot from live CD
  2. Create a mounting point: mkdir /mnt/mybigdisk
  3. Mount another big disk that has space for a single file that is the full size of the entire broken disk: mount /dev/mybigdisk /mnt/mybigdisk
  4. While the broken disk is NOT mounted, copy the partition(s) you want to keep like this: cat /dev/broken_partition1 > /mnt/mybigdisk/part1
  5. Un-mount and shutdown, removing broken disk (it should be kept un-attached and not rattled about for safe keeping).

  6. Boot into your favorite OS and mount your big disk again: mount /dev/mybigdisk /mnt/mybigdisk

  7. Create a mounting point for where you want to try to mount the copy of bad partition: /mnt/my_broken_partition_copy

  8. Proceed to mount the copy of the broken partition from file using loop device like so:
    mount -o loop /mnt/mybigdisk/part1 /mnt/my_broken_partition_copy

NOTE: If the file-system is too damaged, you may not be able to mount without repairing it.

NOTE: If you want to keep the whole disk, or if partition table is screwed, you can also do this on the entire disk. Just swap out /dev/broken_partition1 with /dev/broken_disk1 in instructions above (and mounting the loop device will be a little more complicated after).

NOTE: Even if the file-system is completely broken, you can still dig out data from this block-level copy using all kinds of un-delete/forensics software. Here is a list. That is why it is a good way to go about.

Why is this the next best thing?

Mencahical disks (I am assuming your disk is mechanical, if not it would porbably just not work at all) have a tiny arm inside that moves around to read the data from your disk. If it is somehow broken, then moving this arm might have adverse effects.

The least amount of movement is to read simply the whole disk linearly. That way the arm does not need to bounce around looking for blocks in random order.

Also, in case some areas are "more broken" than others, relying on the metadata of the file-system will not work. It will just retry, fail or do other things that may have adverse effects (move around the arm a lot).

Things to remember:

  1. You should not mount broken disk as it risks breaking the file system. If you MUST mount them, at least mount read-only.
  2. Keep broken disks attached to power as little as possible. Keep disk completely still, any sudden movement may make it worse.
  3. If it starts making bad noises, detach from power immediately.

I hope this is useful.

Mr. Developerdude
  • 771
2

I was getting the same error messages. In my case not the disk was defect, nor the partition was wrong, etc.

The error in my case was a USB-3.0-Plug on the front panel of my PC-case which probably did not follow the specifications. (I think I should install a USB 3.0 frontpanel from a different vendor/make.)

As soon I connected the external HDD via the USB-3.0-Plug on the motherboard (backside of the PC case), things went fine!

In addition: Pay attention to Wireless/WLAN antennas in direct neighborhood to USB-3.0-Plug/Cables! Things are not so "discrete" with USB-3.0 than it have been with USB-2.0 ;-)

Hartmut Pfarr
  • 576
2

There might be another option..

I have the same error when copying small files (1MB) from my NAS to a local Seagate HDD drive. The smartctl tool says the drive is OK, but details show its quite aged and some values are in pre-fail. I had these errors before, then there were absent.

However, interestingly I found that I could copy all files without any error using the command line with "cp file1 /home/$USER/temp". Doing the same with the file manager consistently gave the splicing error.

Although I agree its a wise move to swap the HDD for a new one, I think that there might be another reason behind this...

CatMan
  • 1,399
2

make sure your flash drive is in NTFS instead of FAT32.. then try copying the file over and over, as you can see an option asking if you want to replace the existing file on the flash drive saying "do you want to replace the existing file (e.g. pic001 size: 100KB) with (e.g. pic001 10.1MB)?" those two files are just the same but as you can see with a different file size . choose replace.. now go back to the folder of origin of those files now one by one determine their original file size and do the previous steps over and over again until those copied files have the file size the same as the original ones.. that worked for me well, it will take time though.. hope that helps

MarvinEl
  • 21
  • 1