Re: bug in/triggered by rename() (was :Re: dpkg-source -x *****s system

[Mark Kettenis <kettenis@wins.uva.nl>]

   Date: Fri, 2 Apr 1999 04:47:15 +0200
   From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>

   But it is indeed that you have to type multiple ^C, maybe there are multiple
   levels of this happening or so... however, I chased this one down:

   After using my preferred debuggung strategy (print Beatles songs word by
   word on STDERR), I noticed that the perl script dpkg-source hangs on a
   rename() command. Further testing showed that this bug is triggered by this
   simple C command:

   #include <unistd.h>
   int main (int argc, char argv[])
   {
   return rename("testdir", "testdir");
   }

   You need a (empty) directory "testdir" in the current directory of course.

   This made me look at glibc, sysdeps/mach/hurd/rename.c, which in turn (I
   assume) calls libdiskfs/dir-rename.c, I assume the error is there
   (I tried to understand what's happening there, but I did only grasp parts
   of it, so you have to check yourself, sorry, no patch this time).

Thanks for this VERY USEFUL information Marcus.  The problem is in the
following fragment in libdiskfs/dir-renamed.c:

  /* 1: Lookup target; if it exists, make sure it's an empty directory. */
  ds = buf;
  err = diskfs_lookup (tdp, toname, RENAME, &tnp, ds, tocred);
  assert (err != EAGAIN);	/* <-> assert (TONAME != "..") */

  if (tnp == fnp)
    {
      diskfs_drop_dirstat (tdp, ds);
      diskfs_nrele (tnp);
      mutex_unlock (&tdp->lock);
      if (fdp != tdp)
	mutex_unlock (&fdp->lock);
      return 0;
    }

The diskfs_lookup() call locks TNP, but in the case of TNP == FNP it
is never unlocked.  However I'm not sure what is the best way to do
it.  Thomas, Roland, should we use diskfs_nput() instead of
diskfs_nrele() or should we just put in an explicit mutex_unlock
(&tnp->lock) ?

Mark