Tuesday, December 29, 2009

Ubuntu 9.04: Error While Copying; Folder Contents Not Displayed; Input/Output Error

I was using Ubuntu 9.04 (Jaunty Jackalope) with an internal drive and an external USB hard drive. The latter was a Seagate SATA in a Rosewill RX-358-S SLV enclosure. I copied and pasted a 16GB folder from the internal drive to the USB drive. Those 16GB consisted of 13 files, among which was one large (15GB) VMware virtual disk. The folder I was copying was named VMs. When I copied that folder from the internal drive to the external drive, I got this message:
Error while copying to 'VMs'.


There was an error getting information about the destination.

When I showed more details, it said this:
Error stating file '/media/OFFSITE/VMs': Input/output error

I didn't know what it meant when it referred to "stating" file. Regardless, when I clicked on the target (external) folder, I got this message:

The folder contents could not be displayed.


Sorry, could not display all the contents of [folder name]: Input/output error.

I got the same error message when trying to view the contents of other folders on the external drive. Its contents were visible to Windows XP running on a different computer. The computer on which I was having this problem was able to detect the existence of the external drive and could show its folder tree in Nautilus; it just couldn't show the contents of any particular folder on the external drive. Meanwhile, the internal drive seemed to be working normally.


The Rosewill enclosure had eSATA as well as USB connectors. The same error messages came up with both. One source suggested that the external enclosure's power supply could be malfunctioning. Since Windows could read the drive, I doubted that was the explanation. I had had this problem previously, and had used ntfs-config to solve it, which is why I had installed ntfs-config when setting up the system this time. But the procedure I had most recently used didn't solve the problem this time. Reviewing earlier efforts, I typed "df -h" and confirmed that the external drive (/media/OFFSITE) was indeed at /dev/sdd5, as I had indicated in /etc/fstab. In that case, the advice of pablopancho would be to type "sudo ntfsfix /dev/sdd5" (which should run, at least, because ntfsfix was part of ntfsprogs, which was another program that I was now learning to install when setting up the system, anticipating that I would have NTFS drive problems at some point). This gave me error messages stating a number of failures (e.g., "Failed to determine whether /dev/sdd5 is mounted: No such file or directory" and "Failed to startup volume: No such file or directory") and concluding with this advice: "Volume is corrupt. You should run chkdsk."


So, OK, I connected the external drive to the WinXP machine again and rebooted it from the Windows installation CD. I went into Recovery Mode and ran "chkdsk /r." Chkdsk got only 54% of the way through the job and then stopped and said, "The volume appears to contain one or more unrecoverable problems." I rebooted with the Gparted live CD and told it to check the external drive. It did not complete that operation; instead, it said, "An error occurred while applying the operations." Fortunately, this occurred on a backup drive, so I was able to skip the attempt to recover its data; I figured I would just repartition it and start over.

Before repartitioning, though, just out of curiosity, I booted my laptop into Vista, connected the external drive to that, and was able to copy data from the external drive to the laptop. I assume I would have been able to do the same from a Windows XP machine, but I didn't try. As had happened to me previously, I was finding that Ubuntu seemed to be more concerned about drive imperfections than Windows was. I wanted the drive to be fixed, of course, so I went looking for the way to repair hard drives in Vista. It seemed that Vista was similar to XP in this regard: in Windows Explorer, I clicked on the external drive, right-clicked and selected Properties > Tools > Error-checking. I ran both the "Automatically fix" and the "Scan for" options. It began processing files, one at a time, very slowly. It took hours. In fact, after six hours, judging by its progress bar, it had only processed about one-tenth of the total contents of the drive. Granted, it was a 1TB drive with about 800GB of data. Vista might have finished with a 300GB drive, at this rate, in 24 hours or less. I wasn't inclined to let it churn away for a week, so I canceled. If this process was actually succeeding in recovering data, then I had to say that Vista seemed, at this point, to include an impressive file-recovery capability. But whatever.

I bailed out and took a look at the drive, or tried to. Now Vista said, "Location is not available. F:\ is not accessible. Access is denied." So I tried reformatting the drive. But formatting itself looked like it was going to take hours, so I tried to cancel. Unfortunately, Vista said, "The format could not be interrupted. To attempt to quit formatting again, click Retry. To quit immediately, click Cancel." Retry didn't work, so I used Cancel. I rebooted from the Vista installation CD and went into the Repair Your Computer > Command Prompt option. Chkdsk /? gave me the idea of trying "chkdsk f: /f," but that said "Cannot open volume for direct access." Rebooting back to regular Vista, I clicked on drive F in Windows Explorer. It was now showing as just "Local Disk (F:)," not as the OFFSITE drive. When I clicked on it, Vista said, "You need to format the disk in drive F: before you can use it." So I went with that. But after running all night, and showing what looked like progress to completion on its progress bar, it said, "Windows was unable to complete the format." I rebooted into Ubuntu and tried Partition Manager (Gparted) again. It still showed the drive as being partitioned, but in an unknown format. Since I was no longer trying to save the data, I deleted the partition on that drive and then created a new extended partition and a logical partition, within the extended partition, filling the whole drive, in NTFS format. But the second step didn't complete; instead, Gparted told me that I had to run Windows chkdsk /f twice on this drive. I did that. Then I booted into WinXP and tried copying some data to the drive. I got this:

Windows - Delayed Write Failed.


Windows was unable to save all the data for the file H:\$Mft. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere.
As it turned out, I had two separate problems here. First, my hard drive was full. I doubt I had ever emptied out the root trash, and it turned out that was the bulk of the problem. I've explored that, and other aspects of making drive space in Ubuntu, in a separate post.


Second, I had to play around by trial and error with some technical steps involved in getting the external drive mounted. I worked through that in a forum post. But now I had a new problem. When I tried now to run an rsync backup process, I got this:
rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (490 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.5]
I had to interrupt this troubleshooting for a couple of days. When I came back to it and tried to run the same rsync backup process, I now got a number of error messages along these lines:
rsync: failed to set times on "/media/OFFSITE/[subfolder]": Input/output error (5)
rsync: recv_generator: failed to stat "media/OFFSITE/[subfolder]/[filename]": Input/output error (5)
*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/media/OFFSITE/[subfolder]" failed: Input/output error (5)
Taillessmonkey found that the problem disappeared for him/her when s/he replaced the external hard drive enclosure. I happened to find another external drive enclosure on sale at about this time, and bought that. While waiting for it to arrive, I tried connecting the hard drive internally within the computer I was attempting to back up. When the computer started up, it recognized it immediately as the OFFSITE drive, but I still got some instances of that same "recv_generator" error. Actually, just one. Instead, this time I got dozens of "Input/output error" messages arising from an "rsync: rename" attempt to rename nonexistent files. For instance, one of those input/output errors arose from an attempt to rename a file called "DW_B9154.wav.Mw21w0" to be DW_B9154.wav. But there was no Mw21w0 file, or at least there should not have been. I could only guess that rsync was creating temporary copies of files, during its backup process, and was then losing track of those files before it could delete them. I wasn't sure if that was the case, or what to do about it if it was.

I did wonder, though, whether this might be a problem with the source partition rather than the target. With the backup OFFSITE drive still inside the computer, I ran an rsync to back up another partition to OFFSITE. This one worked just fine. I tried another. That one went with only one error. These same drives had produced numerous error messages when I had tried to back up to them in the external drive enclosure. It seemed that maybe I had two problems: one source partition was messed up, and also the external drive enclosure was no longer cooperating with Ubuntu.

Although that other partition had shown only one error in Terminal when I was running rsync with OFFSITE as the target drive, I was in for another surprise. When I checked the folder on OFFSITE to which that partition's contents had supposedly been copied, Nautilus reported that there were no files in that folder. Yet when I tried to manually copy files over from that partition to that folder on OFFSITE, I got a message indicating that the first of the files being copied already existed on the target. (I had set Nautilus to show hidden files, and anyway these were not hidden.) I went ahead and told it to overwrite the files already existing on the target (OFFSITE); and when it was done, what I saw on the target was

[This is as far as I got on this item.  I am only now getting around to replacing the external hard drive enclosure.  Other external drive bays seem to be doing fine with that same hard drive, so I assume the enclosure was much of the problem.]

0 comments: