GNU bug report logs - #17963
cp: strange behavior (possibly redundant link recreation)

Previous Next

To reply to this bug, email your comments to 17963 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul E Condon <pecondon <at> mesanetworks.net>
To: bug-coreutils <at> gnu.org
Subject: strange behavior of cp
Date: Sun, 6 Jul 2014 18:10:44 -0600

I have a situation in which I want to merge two file
sturctures by copying one of the structures onto the
other with the following command:

cp -aulv arxivBtry1/host/* arxivBtry2/host/

This should, I believe, make hardlinks into arxivBtry2/host/ for any
plain file that is present in arxivBtry1/host/ if a newer version of
that file is not already present in arxivBtry2/host/. And, also I
think that if I interrupt this statement and restart it, it should do
nothing to the hardlinks it has already inserted in arxivBtry2/host/
silently.  But when I try this resume operation I get a long list of
reports of removing files from arxivBtry2/host/. Why? Examination of
arxivBtry2/host/, using ls -la indicates that the file in arxivBtry2/host/
that was reported removed is still there, so the removal reports seem
to be false reports.

More details about the environment:

Both arxivBtry1/host/ and arxivBtry2/host/ are directories on an
external harddisk that has 3 TeraB capacity and is half full. This ls
output:

root <at> big:/media/gfx2/hostmrg2# ls -ls
total 44
4 drwxr-xr-x 3 root root 4096 20140701_144028 arxivAtry1
4 drwxr-xr-x 3 root root 4096 20140630_185519 arxivBtry1
4 drwxr-xr-x 3 root root 4096 20140705_105447 arxivBtry2
4 drwxr-xr-x 3 root root 4096 20140702_071706 glb2try1
4 drwxr-xr-x 3 root root 4096 20140701_154330 glbltry1
4 drwxr-xr-x 3 root root 4096 20140701_150432 mrg4try1
4 drwx------ 3 root root 4096 20140705_102058 sgt1fxd
4 drwxr-xr-x 3 root root 4096 20140702_215246 sgt1xxx
4 drwxr-xr-x 3 root root 4096 20140701_144837 wdp71try1
4 drwxr-xr-x 3 root root 4096 20140701_123858 wdp7vtry1
4 drwxr-xr-x 3 root root 4096 20140630_231448 wdp8try1
root <at> big:/media/gfx2/hostmrg2# 

The other lines in this listing are other directories
each of which also has a sub-directory named 'host'.
Once I understand what's going on, I intend to merge
them into arxivBtry2/host/, also.

I'd be happy to call this behavior a feature, not a
bug, if it is already known to you and known to 
cause not harm to the actual merge of the plain files
of the two structures into one structure. 

Thanks for your help,
-- 
Paul E Condon           
pecondon <at> mesanetworks.net

Message #8 received at 17963 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul E Condon <pecondon <at> mesanetworks.net>
Cc: 17963 <at> debbugs.gnu.org
Subject: Re: bug#17963: strange behavior of cp
Date: Mon, 07 Jul 2014 16:44:16 +0100

On 07/07/2014 01:10 AM, Paul E Condon wrote:
> 
> I have a situation in which I want to merge two file
> sturctures by copying one of the structures onto the
> other with the following command:
> 
> cp -aulv arxivBtry1/host/* arxivBtry2/host/
> 
> This should, I believe, make hardlinks into arxivBtry2/host/ for any
> plain file that is present in arxivBtry1/host/ if a newer version of
> that file is not already present in arxivBtry2/host/. And, also I
> think that if I interrupt this statement and restart it, it should do
> nothing to the hardlinks it has already inserted in arxivBtry2/host/
> silently.  But when I try this resume operation I get a long list of
> reports of removing files from arxivBtry2/host/. Why? Examination of
> arxivBtry2/host/, using ls -la indicates that the file in arxivBtry2/host/
> that was reported removed is still there, so the removal reports seem
> to be false reports.
> 
> More details about the environment:
> 
> Both arxivBtry1/host/ and arxivBtry2/host/ are directories on an
> external harddisk that has 3 TeraB capacity and is half full. This ls
> output:
> 
> root <at> big:/media/gfx2/hostmrg2# ls -ls
> total 44
> 4 drwxr-xr-x 3 root root 4096 20140701_144028 arxivAtry1
> 4 drwxr-xr-x 3 root root 4096 20140630_185519 arxivBtry1
> 4 drwxr-xr-x 3 root root 4096 20140705_105447 arxivBtry2
> 4 drwxr-xr-x 3 root root 4096 20140702_071706 glb2try1
> 4 drwxr-xr-x 3 root root 4096 20140701_154330 glbltry1
> 4 drwxr-xr-x 3 root root 4096 20140701_150432 mrg4try1
> 4 drwx------ 3 root root 4096 20140705_102058 sgt1fxd
> 4 drwxr-xr-x 3 root root 4096 20140702_215246 sgt1xxx
> 4 drwxr-xr-x 3 root root 4096 20140701_144837 wdp71try1
> 4 drwxr-xr-x 3 root root 4096 20140701_123858 wdp7vtry1
> 4 drwxr-xr-x 3 root root 4096 20140630_231448 wdp8try1
> root <at> big:/media/gfx2/hostmrg2# 
> 
> The other lines in this listing are other directories
> each of which also has a sub-directory named 'host'.
> Once I understand what's going on, I intend to merge
> them into arxivBtry2/host/, also.
> 
> I'd be happy to call this behavior a feature, not a
> bug, if it is already known to you and known to 
> cause not harm to the actual merge of the plain files
> of the two structures into one structure. 
> 
> Thanks for your help,

This sounds similar to the redundant link recreation issue at:
http://bugs.debian.org/752892
I've yet to look into these.

thanks,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.