Subject: bug#8636: cp -x flag does not work

From: [email-masked]
Date: Mon, 09 May 2011 06:45:34 -0400

context: copy a linux system to a directory where, after chrooting to that
directory, i could safely  torture and mangle the duplicate system.

the command used was cp -xvdpR /*   /newdirectory

where / contains mounted other(not on the drive / is on) filesystems. these
are nfs mounts(direct and via ssh), mounted hard drives, and mounted loop
drives.

the guilty party is apparently the wildcard

the command as given above copies everything and descends all directories on
all mounted file systems under / no matter what they are.

the command:  cp -xvdp /<otherfs-dir>/*   /newdirectory

descends into the top level of the  otherfs dir and copies the files
therein, but does not descend into other directories.

so the wildcard essentially negates -x and this was not anticipated
behavior. checking the docs i did not find any mention of this.

if this is WAD, then it should be documented, however, i don't think that
someone using the -x wants a wildcard to undo that spec especially in a dir
with several mounts on subdirectories.

however, it is also probably the case that most people wouldn't put a
wildcard in there to do the job anyway(given a -R)...but i'm weird :-)
(well, actually, i thought that it would copy the / itself which would be a
mess, but there may be other situations where it's use is warranted ).

the latter part of the above comment suggests that i have to test what
happens when using ? wildcards.

the command:   cp -xvdpR /mnt1? /newdir

 where there are mounted drives on /mnt1, /mnt11,/mnt12, descended into and
copied everything on all 3 fs. without the -R flag the 3 directories were
excluded.

i didn't provide the items you requested because in the context of the above
discoveries i didn't think it was relevant, this happens no matter what the
drives are.

any other info you need or testing done, let me know, and thanks

fractoid

On Sun, May 08, 2011 at 07:32:08PM +0200, Jim Meyering wrote:
> [email-masked] wrote:
> > coreutils 8.12, i don't know if this problem existed in previous versions.
> >
> > copying the root directory ( / ) of a running linux system using cp -xdvpR
> > cp followed a directory that was mounted via NFS under / . the copy was
> > stopped before any other directories on other filesystems were copied so i
> > can't speak about how cp would handle those mounts.
> 
> tags 8636 + moreinfo
> thanks
> 
> Thanks for the report.
> 
> AFAIK, cp's -x (--one-file-system) option does work.
> If it's not working for you, perhaps there is something
> unusual about your situation.  What does "df" say about
> the NFS-mounted directory that was mistakenly copied?
> 
> To test it without copying data unnecessarily, I ran this:
> 
>     mkdir junk && cp -srx / junk
> 
> That makes symlinks to the same files that a one-file-system "cp" would
> have copied.  The only nonempty directories in junk/ correspond to ones
> in "/" that reside on the same file system as "/".  So at least for me,
> it works as advertised.  Note that copying each top-level mount point
> directory is expected -- those are all empty in the destination (junk/
> in my case).
> 
> Please provide more details, including
>   - the precise command you ran
>   - a sample of the output showing it copying a file that it shouldn't
>   - what this prints: stat --format=%04D:%n / DIR
>       where DIR is an NFS-mounted directory that was mistakenly copied