I'm not new to computers, but I'm pretty new to Linux so I'm not sure exactly what happened under the hood here...

I was trying to copy a file from my desktop to my Windows partition in Ubuntu Desktop 7.04.

The Windows partition is NTFS, and I didn't set up NTFS-3G yet, but I didn't know at the time that NTFS is read only by default.

The exact command I did was:

sudo cp ~/Desktop/windows.iso /dev/sda1

Now I realize a) my drive was mounted under /media/sda1 and b) I should have specified the filename as in /dev/sda/windows.iso. I used sudo because when I tried to drag and drop to the drive, it said I didn't have write permission. I didn't realize at the time that it was because NTFS was read-only...

windows.iso is the vmware tools package that came with vmware server. Now, I have a volume mounted labeled "vmware tools", and parted sees a 20gb partition that used to be my Windows partition as an unrecognized filesystem.

So... what happened? Is my partition lost? Is there a way to repair it? Did I actually replace an entire 20gb partition with a 13mb ISO? Or did something else happen under the hood here?

Thanks for any insight...!

Welcome to LQ!

That was a clever and powerful command you issued there. You copied the ISO file to the raw device sda1 effectively ignoring the filesystem on it. Doing that you destroyed the filesystem structure. In other words, your Windows is fubared now.

Does that mean there is no way to repair the damage?

You overwrote first 13 MB of your Windows partition. Everything located there is gone for good. The rest of sda1 may be salvaged ... probably. Do not know a thing about NTFS nor tools that work on NTFS.

You've discovered the reason we tell people not to run as root. When you do things as root (even through sudo) the system assumes you know what you want to do. In this case, that was to overwrite the /dev/sda1 partition with the iso file. Writing to /dev/sda1/SOMEFILE would have failed, as /dev/sda1 is not a directory.

I would try running a program called 'testdisk'. It can (often) recover filesystem structures from backups later in the filesystem. The first 13MB is gone though. You're lucky the file was so small.

Yes, but doesn't that mean that he's lost his entire directory tree? Sure, much of the data is there, but only as raw data. There's no practical way to get at it in any useful manner, is there?

Thanks for the info everyone. Now to see if I can salvage the rest of the drive...

I would tend to agree with Quakeboy02. I'm not as educated in ntfs as Fat, but the first sector (512B) of a partition is usually used/reserved for boot code. The next two sectors (if I remember correctly), is the Fat (file allocation table), which is the directory structure to find files in the partition. I believe ntfs is not much different, Linux file systems use "super blocks" spread through the entire partition for the directories.
So using photorec or foremost can retrieve lost data in the partition, but the data at this point cannot be found through a format structure.

The bootblock, partition table, and partition boot sector are all gone.

The bootblock can easily be rewritten, and there are any number of tools that can take a good stab at recovering the partition table. In fact, if the end of the first partition can be unambiguously identified, then the partition table for the first partition can be rebuilt manually with only a moderate amount of skill required (you simply assume it starts on the Cylinder 1).

The NTFS filesystem can be recovered far more easily than you might at first think because there is a duplicate copy of the partition boot sector at the end of the partition.

I really doubt that the system will boot after recovery; good chance that ntldr was taken out as well as boot.ini. But the drive is certainly recoverable.

Actually, it had never occurred to me that it was possible to write directly to /dev/hda; I would have expected the lack of a filesystem to prevent that. Other than with dd, I've never tried it.

Might be worth some fooling around; I wonder if an iso could be copied directly to a device using cp and have it work...

Same question was poking at me.

Copying data directly to a device is certainly possible. All 'dd' does is open it like any other file.

As jiml8 points out, there is a backup copy of the filesystem structures in an NTFS partition. testdisk can usually recognize this and repair it. I also agree that it's unlikely to boot: the early files are likely to be critical ones.

Ok, in case anyone is curious, an update.

I ran testdisk, and used it to rebuild the rebuild the bootsector and repair the mft.

Then, I booted off the XP SP2 CD and from the recovery console, did chkdsk and then fixboot.

Now, amazingly, XP boots, though some things are a little screwy, like my taskbar is stuck at the bottom like I dragged it to be no lines tall, if that makes sense. It just looks like the top edge of the taskbar, but I can't drag it taller, even though the mouse changes to the up and down arrow draggy thing.

Most things appear OK. I think I can repair the Windows partition using a repair install.

HOWEVER, in ubuntu, the partition still doesn't show up under "my computer". I still see "vmware tools" as a volume. Is there something I can do to have ubuntu "reset" things, like redetect all my partitions or something? It also doesn't show up in the Hardware Information applet (vmware tools does), though testdisk and parted appear to see the partition OK.

I wonder what Windows System Restore would do at this point for Windows?
Sometimes, when Windows reports errors, Linux will not mount it till Windows reports all errors fixed, rebooting Windows twice has been recommended to take care of that (not sure of the validity of this). Make sure the entries are still there in fstab.

Let's see the output of (that's a lower case ell in the first command)

Wow! Looks like filesystems have come a long way since I looked at FAT and UDF.