Failing to copy large file to external drive

Hi, sorry to state the obvious but I am new to Ubuntu Mate, coming over from the Windows world. I have been trying to copy a large VirtualBox vdi file to an external drive. I have tried this on two separate external drives but keep getting the same fail. Oftent at 53.4 GB of 68.7 GB the copy process fails and says: "Error splicing file: Input/output error". I then tried formatting one of the drives to Ext4 (from NTFS) and got the same fail at 8.1 GB. I decided to try booting from my live Ubuntu-mate USB and try the same thing. Failed at 53.4 GB. Can anyone give me any direction?

I have had that problem with large files going to external drives. It seemed to me to be perhaps a problem with buffer over/under run to the USB devices.

What worked for me was using rsync instead of cp to move files. You can get a progress indicator with rsync also, and you can do various check and recovery options (man rsync) YMMV. I never worked further on the details of why.

1 Like

I googled your error message and found this short video. I have no idea if it will work but it's a quick fix if it does.

Thank you. I am currently inept at the command line. But something else I tried did not work so I might have to look into the rsync process.

Well, that certainly did seem to be a similar problem. Sadly it did not work. Still failed at 53.4 GB

I don't know what container a .vdi file is--but if it is only one file as far as the filesystem goes, it should be as simple as
$rsync -avvz --progress <sourcedir>/<sourcefile> <destdir>/

I'm guessing your <destdir> is something like /media/<username>/<deviceid>

You would open a terminal (Ctl-Alt-T usually). $ls -la will list dir contents. $cd will change directory. So to find out your destination mount point you could:
plug the disk in
open a terminal
$cd /media/<username>
$ls -la
make note of the disk's device id
$cd <path>/<to>/<vdi file>
$rsync -avv --progress <vdifilenamd> /media/<username>/<deviceid>

An alternate way is to enter the command $mount. This will show all mounted devices. Near the bottom you should see your external drive as <drive> on /media/<username>/<deviceid>. Then you can use that mount point directly in the rsync.

rsync is particular about the trailing slash on paths. But the manual has excellent usage examples near the beginning. The -a option preserves file owner and permissions (archive). The -v (verbose) lets you better follow what is going on. The -z option compresses in case you are sending over a slow network. If all the disks are on your local machine you don't need that one.

By the way, I'm assuming your external drive is formatted ext4. If not, you'd have to modify the -a option. Some of the preserved info may not translate to ntfs.

Hallo JeffH

Don't panic...

The good news is that you can use rsync without the commandline :slightly_smiling_face:

There is a GUI for rsync called Grsync... and this video will show you how to get started:

Good luck. :slightly_smiling_face:

1 Like

Now that's helpful! I had not run across it before.

I've also edited the command line snippets above. The original posting didn't have them marked as pre-formatted, so they were displaying very deceptively wrong.

Thanks alpinejohn and charles-nix. So, I have come to the conclusion that I just have a seriously messed up file. (that I was trying to copy over to my external drive). A little background on it. It was originally a dynamic hard drive file for VirtualBox. I changed it to a larger fixed drive using some tools within the VirtualBox package. I probably should have mentioned that but it didn't occur to me until last night that the file itself might be the problem. So last night I installed the front end for rsync and tried to copy the file. (meanwhile cursing my ineptitude at the command line. Sorry Charles) After it copied the file (took a really long time by the way) it said something like copied the file with errors and when I tried to copy the error box and paste it into a file it wouldn't let me, saying that every place on my computer was read only. (I don't know what I'm doing) So I eventually rebooted, and Ubuntu-Mate won't boot. Got to a screen that said (initramfs). So, this particular file is important to me. It is a Win7 all set up installation in VirtualBox. So I try using another live linux version to copy the file over and it fails at 53.4 GB. And then it dawns on me that the file is goofed up. So, I am writing this in SparkyLinux trying to think about what to do next. I need my Windows installation primarily for my work (I do woodworking and use CorelDraw for design) Before you suggest that I stay with Windows there is a reason that is pointless to go into. Just want to say I so appreciate all the help you all have given me!

I'm trying to think how a "messed up file" could cause your problem. As far as cp or rsync or mv is concerned, the source is just a stream of blocks of bits. They don't care whether the blocks make "sense" or not.

Do you suppose you have an unrecoverable disk error on the source disk? Is the source disk NTFS? If so, can you go back to a Windows system to have tools to diagnose/repair the problem? I would be reluctant to go mucking about on an NTFS disk with Linux tools.

It is formatted ext4. But... It is a fairly old drive. Another reason I thought it might be the file itself is because I have the original dynamic vdi file which is somewhere around 59 GB and cp handled it with no issues.

You can use gparted (GUI) from a LiveCD to check the disk for bad blocks.

I checked it and it didn't seem to find a problem. (It didn't give me a log output though) One other idea I had is that there is no dedicated swap partition. When I installed Ubuntu-Mate I just kept it simple. Not sure if that could explain it or not.

Swap is not required until you run out of RAM for processes. With that copy, you'd use a lot of ram for disk cache--but that's not required--just makes things faster. If you really ran out of RAM and had no swap, the kernel would kill user processes to preserve its own operation. Even without a dedicated partition, you may have a swap file, which would be as good for this purpose.

This (similar) question suggests using scp instead of cp. The discussion there also gives methods for checking the disk for errors.

https://askubuntu.com/questions/509695/cp-fails-to-copy-with-errors-cp-error-reading-file-input-output-error-and

Another place to look is motherboard/RAM errors. Maybe you have something going bad. For instance, some linux setups, when disk errors occur, will remount the faulty partition read-only to preserve the existing data. Could that be what happened when you couldn't access your disk?

Right now, on my system,
$ mount | grep errors
gives a list of disks mounted with the mount flag errors=remount-ro
One of those is a USB stick, mounted on /media.

What that means is if there is an error detected in reading or writing to/from the USB, the USB will be remounted read only. I think that is the default for Ubuntu, but you should check with the mount command above and your external disk plugged in.

So perhaps it is an error on the receiving end, causing a remount read-only? Maybe check the external disk with the disk tool (GUI) or e2fsck.

Just trying to think of what I would try next if I were in your shoes :slight_smile:

In my experience, an input/output error is very likely down to hardware -- whether it's USB controller playing up or the disk itself getting old and worn when it reaches those sectors. The last few lines in the kernel log might have more nitty gritty details when the error happens:

/var/log/kern.log

(Can be accessed from Applications → System Tools → Log File Viewer in Ubuntu MATE, or cat command in the terminal)


If you've got another computer, you could try taking the drive out and plugging it into another machine, preferably directly into the motherboard (with a IDE/SATA cable, if it's a desktop) or USB drive enclosure.

Unfortunately, if I understand the situation that now the system's disk is unbootable containing the file you'd like to copy - it sounds like it's going faulty. :frowning: Performing a short S.M.A.R.T. self-test (in the Disks program) will confirm if this is the case.


Another possible solution is to create an image of the problematic disk, but you'll need another drive that's larger then the source drive or partition. A tool like ddrescue (packaged as gddrescue) should help with this, since it will keep on going... but if it's a hardware failure, I/O error will creep up again.

If it's something you'd like to do - see the "Imaging a damaged device, filesystem or drive" section at https://help.ubuntu.com/community/DataRecovery - it is terminal stuff though.

If an imaged copy of the 'problematic' disk succeeds, you'll be able to mount it and try copying the file again.

1 Like

Thank you. That gives me a lot to work on. I did do a memory check and that was okay. Hopefully not a motherboard issue. I will start checking the drives and perhaps order a new one. Meanwhile I'm going to start rebuilding my system with care, and try to learn about Clonezilla. So I have something to go back to if something like this happens again.

Hey thanks for your suggestions Luke! There are so many tools to help in situations like this that I don't know about. I have taken the precaution of ordering another drive with better capacity. In the short term I think I've decided not to over worry about the file in question. Just going to reinstall everything. All my personal files on Ubuntu and Virtual box Win7 are safe. Then I can start checking these drives. It is noteworthy that the problem happened on two separate backup drives. So perhaps it is motherboard/USB related. At any rate thank you very much.