The reason I opted for mc in the first place was for the ability to tag or untag directories to avoid copying /proc and the /mnt directories. Since it had the option to retain UID's and GID's I thought it was a safe option. I backfired on me which I think is a bug and will report it as such.
I will say that other than the directory permissions it worked well. I should have followed my usual procedure of dbl checking before I removed the old file system. The linuxconf suggestion changed some of the permissions for me. The system is working without any errors other than the smail error. I think I should be able to operate without re-installing and fix the permissions as I go. Thanks to everyone for the helpful advice. On Tue, 29 Apr 1997, Robert D. Hilliard wrote: > On Tue, 29 Apr 1997 Nathan E Norman <[EMAIL PROTECTED]> wrote: > > -------------------------snip------------------------------------------ > > Using the correct tools is important. David gives you one such tool - I > > personally type the following command in the directory I wish to copy: > > "find . -print | cpio -p /target". This is of course a simplification; > > find and cpio have a lot of powerful options, and people will argue the > > merits of tar vs. cpio all day. It works for me. At any rate, mc is not > > up to the task. > -------------------------snip------------------------------------------ > > I use a modification of this command that was once recommended on > one of the comp.os.linux.* newsgroups: > find <old_path> -depth -print0|cpio -pdm0 <new_path> > > The '-m' option preserves file modification times, which is nice. > I don't know how important the other options are, but they work for me. > Similarly, I don't think the -depth option for find is needed, but I > still use it because that is what was recommended. > > If you copying an entire file system you would cd to root before > giving 'find .'. If the file system is mounted du /proc returns zero, > since /proc is a pseudo file system that (I believe) references > various segments of the kernel image, but find/cpio copies at least > 30 MB of the kernel image into /proc on the new system, which isn't > good. > > Another problem with issuing this command from a mounted > filesystem is that it will recursively copy /mnt (or whatever node the > system is being copied to), which will soon fill your disk. If your > old system is on one partition, this can be prevented using the -mount > or -xdev options to find. > > To avoid copying some directories, such as /proc or /mnt, there > is a -prune option to find (you can't use -depth with -prune), but I > haven't been able to make it work. Instead of using '.' for 'old > path', you can include each directory under / manually. This is a > little tedious to type in, but works well. > > If you have a rescue partition the simplest system is to boot the > rescue partition, mount the old filesystem on one mount point and the > new file system on another mount point, and give the command: > find <old-mount-point> -depth -print0|cpio -pdm0 <new-mount-point> > If the old file system is on several partitions, some creative > modifications are necessary. > > Bob > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > > --Rick [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
