Subject: bin/4344: cpio link bug
To: None <gnats-bugs@gnats.netbsd.org>
From: None <sp128@ibm.net>
List: netbsd-bugs
Date: 10/24/1997 23:18:22
>Number: 4344
>Category: bin
>Synopsis: cpio breaks hard links
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: bin-bug-people (Utility Bug People)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Oct 24 22:20:01 1997
>Last-Modified:
>Originator: Steve Peurifoy
>Organization:
>Release: 1.2G
>Environment:
System: NetBSD axel.home 1.2G NetBSD 1.2G (AXEL) #0: Mon Sep 1 19:46:08 MDT 1997 root@axel.home:/usr/obj/sys/arch/hp300/compile/AXEL hp300
>Description:
If cpio -p or cpio -i is used to copy or restore a file tree with
a fairly large number of hard linked files, some of the links
will be broken in the destination.
>How-To-Repeat:
Execute find ./usr -print | cpio -pdm /newusr
Compare the link counts of the source and destination files
>Fix:
The problem is in the link hash lookup code in gnu/usr.bin/cpio/util.c.
Looks like a botched cut'n'paste. I have also reported this to FSF but
it looks like it's been a while since anyone touched cpio. This problem
still exists in the latest version (2.4.2).
A patch follows.
*** util.c 1997/10/24 17:55:26 1.1
--- util.c 1997/10/24 20:35:03 1.2
***************
*** 601,608 ****
temp = (temp + 1) % hash_size)
{
if (hash_table[temp]->inode == node_num
! && hash_table[start]->major_num == major_num
! && hash_table[start]->minor_num == minor_num)
return hash_table[temp]->file_name;
}
}
--- 601,608 ----
temp = (temp + 1) % hash_size)
{
if (hash_table[temp]->inode == node_num
! && hash_table[temp]->major_num == major_num
! && hash_table[temp]->minor_num == minor_num)
return hash_table[temp]->file_name;
}
}
>Audit-Trail:
>Unformatted: