[PATCH] (against 1.4.2) prevent cp of dir into itself (reprise)

[S H]

vda:

The patch you proposed handles most test cases, but leads to the creation of many-nested directories under the following scenario:

% mkdir -p sub/dir dir
% ln -s sub/dir dir/ldir
% busybox_vda cp -R dir sub sub [XXX]
cp: skipping 'dir/lsub/lsub' - recursive copying detected
cp: skipping 'sub/dir/lsub' - recursive copying detected

(long delay while sub/sub/sub/sub/sub/sub ... etc. is created)

sub/sub/sub/sub/sub/sub/.../sub/sub/sub: No such file or directory

It works fine for the other test cases I have:

% busybox_vda cp -R sub sub  [OK]
% busybox_vda cp -R dir sub [OK]
% busybox_vda cp -R sub lsub [OK]
% busybox_vda cp -R lsub sub [OK]
% busybox_vda cp -R sub dir [OK]

I think the patch you provided doesn't work in this situation because it remembers only the top level directory; in this case, dir has a subdirectory that points to within the destination -- which was not remembered?

The patch that I provided against 1.4.2 is resiliant against the above scenario. I think that the "tree depth" problem would apply to the normal use for the hashtable as well (i.e., the link table). You're right -- my patch should definitely not try to copy every single pathname into the hashtable. I intended only to copy directory paths.

Attached is a revised patch against trunk svn (r19704) which only copies dir pathnames into the ino_dev_hashtable; it was tested against the previous testcases I've mentioned and the scenarios described above.

Thanks for your time.

----- Original Message ----
From: Denys Vlasenko <vda.linux at googlemail.com>
To: busybox at busybox.net
Cc: S H <sh4d0wstr1f3 at yahoo.com>
Sent: Saturday, August 25, 2007 5:03:57 PM
Subject: Re: [PATCH] (against 1.4.2)  prevent cp of dir into itself (reprise)

On Thursday 23 August 2007 22:16, S H wrote:
> cp -R sub sub results in a nasty subdirectory tree (see
> http://bugs.busybox.net/view.php?id=1412). coreutils cp stops it before it
> goes out of control. FreeBSD ignores it. I prefer the coreutils behavior.

...

I would rather no use inode_hashtable. Who knows how deep that tree is,
and inode hashtable actually remembers *each pathname*!!

Please download svn version (yes, it has changed since 1.7.0 in that area),
apply attached patch and try your testcases. Does that work?

The solution is a hack (need to avoid using static), but the basic idea is
to remember a dev and inode of top-level created directory,
and refuse to copy it if it turns up as a source later.
--
vda





       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox.quintessence.r19704M.2
Type: application/octet-stream
Size: 1428 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070827/d8772e55/attachment.obj