We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now


copy drive contents to a blank drive

Joe Rud
Joe Rud asked
Medium Priority
Last Modified: 2008-01-09
I'm trying to copy the contents of a hard drive to another drive.  The source drive is dying (HW failure), but I'm able to read it via an external USB enclosure using Knoppix.  I don't know *nix that well, but I'm *fairly* comfortable working with it.  The plan is to install Windows XP on a fresh hard drive then, copy this backed up data (if it ever backs up) over to new hard drive.

I'm trying this as root, because I figure that gives me the most privileges.

so far I've done:
#chmod 777 source
#cp [-f] [-r] source destination

(I've tried both -f and -r independently and together)

The problem is that I keep getting errors such as:
cp: omitting directory ....

Please help - I've been working on this for far too long.  I'm getting burnt out on this one, and my client wants this done.
Watch Question

Artysystem administrator
Top Expert 2007

cp -Rp source destination
Joe RudSystems Administrator


after running command: #cp -Rp source destination
I'm getting errors:

cp: cannot create regular file 'some destination file': Operation not supported

cp: failed to preserve ownership for 'some destination file': Operation not supported

cp: connot create directory 'some destination directory': Operation not supported

getting MANY of each of these for multiple files.
Artysystem administrator
Top Expert 2007

can you create any file on in destination directory manually (touch /dst/dir/filename) ?
Joe RudSystems Administrator


Yes, created file with no problem

try listing the contents through cat. preferably one from "cannot create regular file 'some destination file'"

cat some/destination/file

if the file scrolls through without giving errors then we know that the read is successful.  if there is a "error reading inode # xxxxx" we know that the disk has bad sectors or a corrupt inode table.
Artysystem administrator
Top Expert 2007

I guess that destination filesystem has FAT32 type.
Then you may ignore 'failed to preserve ownership' message.
What about 'cannot create regular file'  and 'cannot create directory'

I see the only teo  possible reasons:
1) You have incorrect filesystem type when mounting (like MSDOS instead of VFAT).
2) You have  incorrect file/directory name for FAT32. Something very long or with special characters.
Joe RudSystems Administrator


I'm reformatting destination drive, since it seems like that might be part of the issue.  Should I format as FAT32 or NTFS?
Joe RudSystems Administrator


Nevermind.  NTFS it is.

Hi there Geisrud,
One of the problems you might run into when copying from a linux file system, such as ext2, to a windows file system, is file name clashes.  On linux you could have

/path/something <- a file
/path/Something <- a different file
/path/somethinG <- a directory.

note that the files and directory would be able to all co-exist in the same location (/path/) on a case sensitive file system, but on a windows file system, you are going to effectively have multiple entries with the same name.  This could be causing your problems, and I will asume that it does, so here is the solution.

You can also have special files, such as block devices, character devices, soft-links and fifo pipes.  These you can probably just discard as they don't contain data in any case.

There are a few possible ways to solve this.  My first suggestion would be to just tar up the drive, example

tar cf /destination/archive.tar /path/to/source

This would however create a HUGE archive.tar file which will contain every single file on the hard drive.  This is not possible on FAT32 / DOS / etc if the to be backed-up disk contents is more than 2 GB.  Also writing to NTFS as the target is difficult under best of conditions, and not supported under most conditions, so my second suggestion:

You need to get rid of "clashing" file names.

first use the copy process as you have been doing above, but record the output into a new file, eg

cp -r /source /target 2>&1 |tee  /tmp/copy_process_log
or better:
find . | cpio -pdmv /destination 2>&1 | tee /tmp/copy_process_log

You will end up having probably most of your files copied.  You will also now have a log file of the failures.  This is where the beauty of Linux and Unix in general comes in.

Next extract a list of the failed files from the log: depending on how many, the easiest way might be to just edit the log file generated.  Remove everything from the file, but leave only the file names, one per line.  If many files has failed to copy, you could script this with "cleanup" using sed, but for that I would need to know more detail of the exact error messages.

Once you have a list of files, one per line, you can use this to automatically re-copy only those files.  So the next thing to do is to create a second directory so that these files cannot clash with your existing files.  Eg:

mkdir /destination/second_pass
and now copy the files in the list (This is why cpio is better)
cpio -pdmV /destination/second_pass 2>&1 | tee /tmp/copy_pass2_log < /tmp/list_of_failed_filenames

When you generate this list of files you may discover other things:
A small number of directories might each have multiple files with similar names except for case.
Some of the files you may not care about.  Delete these from the list.
Some of the files you might just copy by hand to specific locations.  Remove these from the list and handle them by hand.
Essentially: Simplify the list.

Note that on the second copy pass I again recorded the output of the process to a new log file.  This is in case a third pass is needed.  There are many other ways to solve this particular problem - you might for example tar just the problem files, or rename them by a script.  Here is a method which would use a rename process:

cat list_of_failed_filenames | while read LINE
  echo Moving \"${LINE}\" to \"${LINE}.$T\"
  mv "${LINE}" "${LINE}.$T"
  let T+=1

After running this script, which depends on the list you made above, re-run the copy process as you did initially, but be aware that every file will be renamed to get a number appended to the end of the file name, eg this number will be after the .jpg or .doc or whatever other extention you may have.

Also as a side-note:  You will probably discover that the cpio copy creates the files under /destination/source/...

This could be avoided by doing :
cd /source; find . | cpio ....

But don't do that, because you will probably re-use the lists of files and might move lists between cpio and cp, and not always be in the right directory, and and and....  Rather let the extra parent directory be created and remove it afterwards (It is very quick to remove this extra directory when all your copy work has been completed, even under Windows.)

P.S. good luck!
Joe RudSystems Administrator


So much for drag and drop eh?  I'll try to follow those suggestions as best I can.  I won't be able to work on this until this evening, so please bear with me.  Any other suggestions, let em fly.  I'll let you know what happens.
system administrator
Top Expert 2007
> Nevermind.  NTFS it is.

That's not good news. The better it whould be to format the partition  as FAT32 (it's better supported from Linux then NTFS), then copy files, then (from Windows) convert it to NTFS if you like.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

You need FAT32, because Linux only has read status on NTFS by default, unless you use ntfs-3g or captiveNTFS (which I've never got working anyway)  CaptiveNTFS is a total waste of time IMO and ntfs-3g is a headache you don't need.

Use FAT32 on the destination drive and just use drag and drop, it shouldn't be that difficult as Knoppix puts a mount icon for each drive/partition on the desktop.

You just need to understand the Linux HD/partition naming system

The first partition on the dodgy HD will be hda1 (C in windows)
If the destination drive is the second HD, it will be hdb?  where ? is a number from 1 to whatever, depending how many partitions it has
Joe RudSystems Administrator


I'll try to format as FAT32
first and foremost, let me say this is dangerous if you don't do it right.  that being said....

you can make an exact image of the drive.  when i say exact, i mean exact.  partition table and all.

find out what your source and destination drives are.  assuming that the source drive is "/dev/hda" and the destination drive is "/dev/hdb"

using the command:
     dd if=/dev/hda of=/dev/hdb

When you do this, all data on /dev/hdb will be destroyed and overwritten with that on /dev/hda.  I wouldn't look at this as a permenant solution because you'll lose some of the space on /dev/hdb (the drive will think it's the same size as the original, hence if the original was 40 GB and the new one was 160GB that will be 120GB of lost space).

Hey, at least you'll have your data.  In the future though.....MAKE BACKUPS!
Joe RudSystems Administrator


I was able to format as FAT32 after I created a partition <32GB.  I working on transfering files.  Updates soon!
Joe RudSystems Administrator


Once I created a <32GB partition and formatted as FAT32, drag and drop copying went flawlessly.
Artysystem administrator
Top Expert 2007

Thank you, Geisrud. Have a nice Windowz :-)
Joe RudSystems Administrator


I'm just glad this job is done!  Thank you.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.