> It seems really impractical to try to "copy" the data from one
> disk to another (correct me if I am wrong, please) because symlinks
> tend to get lost or messed up.
>
> It seems really impractical to try to "copy" the data from one
> disk to another (correct me if I am wrong, please) because sym
On Wed, 7 May 1997, Robert D. Hilliard wrote:
> On Date: Wed, 07 May 1997 "David B. Teague" <[EMAIL PROTECTED]> wrote:
> > On Tue, 6 May 1997, Robert D. Hilliard wrote:
> >
> > > cp -ax certainly is much simpler than using find and cpio. Is
> > > there any option to cp (I can't find one) that wo
> Some time ago it was rumored that cp cannot copy files with holes, it
> just fills the holes :-( There's even a package to work around this,
> perforate. Is it still true that cp -a cannot preserve holes?
>
> Carlos
No, this rumor is quite easy to falsify. GNU cp makes a copy with
holes iff the
This is why I thought my brain storm of using MC to tag/untag directories
was the ticket with the retain UID/GID set. Ofcourse since it didn't keep
the permissions of the directories this was a bite in the ass.
However! If you use mc to tag/untag the proper directories and type "cp
-a [^C t] /m
On Date: Wed, 07 May 1997 "David B. Teague" <[EMAIL PROTECTED]> wrote:
> On Tue, 6 May 1997, Robert D. Hilliard wrote:
>
> > cp -ax certainly is much simpler than using find and cpio. Is
> > there any option to cp (I can't find one) that would keep it from
> > copying /proc, like the -prune optio
Roughly two months ago I did this exact same thing, three times!
Without regard to the options I passed to cp, it *did* do a recursive
copy of /mnt, hung on /dev, and I don't remember what happened to /proc.
What *did* work for me what this (I think):
in root directory,
cp --archive /dir1 /dir2
Some time ago it was rumored that cp cannot copy files with holes, it
just fills the holes :-( There's even a package to work around this,
perforate. Is it still true that cp -a cannot preserve holes?
Carlos
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTEC
On Wed, 7 May 1997, David B. Teague wrote:
>
> On Tue, 6 May 1997, Robert D. Hilliard wrote:
>
> > cp -ax certainly is much simpler than using find and cpio. Is
> > there any option to cp (I can't find one) that would keep it from
> > copying /proc, like the -prune option in find?
>
> Isn't /p
On Tue, 6 May 1997, Robert D. Hilliard wrote:
> On Tue, 6 May 1997, you wrote:
> > I agree with Rick M. on this one, although I would suggest adding the -x
> > option. This way if there are any additional mounted file systems, like
> > user, or home, then they will be left off the copy and can be
"David B. Teague" <[EMAIL PROTECTED]> writes:
> Actualy, I'm a lot more concerned with the problem of recursive copy in
> something like.
> cp -ax / /mnt :(
So just do
(cd / && cp -ax `ls | grep -v mnt` mnt)
or something similar.
--
Rob
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-
-BEGIN PGP SIGNED MESSAGE-
On Wed, 7 May 1997, David B. Teague wrote:
>Isn't /proc a mounted file system, even if it is a pseudo file system?
>Doesn't that make x option (which prevents other mounted file systems
>from being copied) the solution to this problem?
yes
>Actualy, I'm a lot
On Tue, 6 May 1997, Robert D. Hilliard wrote:
> cp -ax certainly is much simpler than using find and cpio. Is
> there any option to cp (I can't find one) that would keep it from
> copying /proc, like the -prune option in find?
Isn't /proc a mounted file system, even if it is a pseudo file syste
On Tue, 6 May 1997, you wrote:
> I agree with Rick M. on this one, although I would suggest adding the -x
> option. This way if there are any additional mounted file systems, like
> user, or home, then they will be left off the copy and can be mounted as
> before on the new system.
cp -ax cer
This is more rude then that nice 'find' usage, anyway I moved an old
Slackaware from the partition where I originally installed it to another
partition just doing this:
tar -cSpf- . | (cd /mnt/.; tar -xvSpf-)
Then I replaced two characters in /etc/fstab and everything was working
absolutely
find . -mount -depth -print|cpio -pdmv /newtempmount
I have used this under Dgux, Sunos, Solaris and Hpux, and it has
always worked correctly (although under Sunos and Hpux the switches
are slightly different). I have used it to move root /usr and
Oracle database volumes under Solaris. Time stam
On Tue, 6 May 1997, Rick Macdonald wrote:
> Ken Gaugler wrote:
> >
> > Yeah, that time is here again, when I need more disk space. I
> > have been thinking about moving my Debian to a larger drive, so
> > I can take out the smallest drive to make room for a big one.
>
> Here we go again.
>
> Y
I forgott about this one. This is the one I would use if I had to do over
again.
My perdicament is what Rick is refering to when he says here we go again,
I believe :)
On Tue, 6 May 1997, Rick Macdonald wrote:
> Ken Gaugler wrote:
> >
> > Yeah, that time is here again, when I need more disk s
You will get plenty of advice about this. I just did the same thing,
using copy in mc. mc has an option to maintain UID and GID on copy. It
only worked for the files. The directories were made with root's umask.
I didn't loose any symlinks. The only problem I had was the directory
permissions
Ken Gaugler wrote:
>
> Yeah, that time is here again, when I need more disk space. I
> have been thinking about moving my Debian to a larger drive, so
> I can take out the smallest drive to make room for a big one.
Here we go again.
You're gonna get endless messages with cpio and tar flags and
19 matches
Mail list logo
