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: