Date: Mon, 14 Oct 2002 16:28:42 +0100
From: "Richard Dawe" <rich AT phekda DOT freeserve DOT co DOT uk>
Sender: rich AT phekda DOT freeserve DOT co DOT uk
To: djgpp-workers AT delorie DOT com
X-Mailer: WinNT's Blat ver 1.8.6 http://www.blat.net
X-Mailer: Emacs 20.5 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
Cc: jim AT meyering DOT net
Subject: RESEND: DJGPP CVS and Fileutils 4.1: rm assertion [PATCH]
Message-Id: <E1816yv-0000xc-00@phekda.freeserve.co.uk>
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Below is a patch for the problem that Andrew Cottrell found, when
building gcc 3.2 under Windows XP with fileutils 4.1 built
against DJGPP CVS.

---Start clipping of Andrew's description---
Test directory setup:
    -Created a test directory C:\dj204\test
    -Created a sub directory C:\dj204\test\test
    -Created one file in the subdirectory C:\dj204\test\test\test.c

DJGPP_204 C:\dj204>rm -rf test
Assertion failed at remove.c line 727: fs->have_device
Exiting due to signal SIGABRT
---End clipping of Andrew's description---

After applying the patch below and rebuilding rm, the assertion
is no longer hit. NB: remove.c is used by mv too.

The reason we don't see this problem with fileutils 4.1 built
against DJGPP 2.03 is that 2.03 does not have a d_type field
in struct dirent from <dirent.h>. The comment in the patch
explains what happens for the rm built against CVS.

I've just done release 3 of fileutils 4.1, to fix
some DJGPP-specific bugs in ls. I'll put this patch in release 4,
whenever that happens. For now I'll put the patch in my DJGPP area:

    http://www.phekda.freeserve.co.uk/richdawe/djgpp/fileutils/4.1/

Bye, Rich =]

--- remove.c.~1~        2002-06-11 13:41:50.000000000 +0000
+++ remove.c    2002-10-14 15:35:00.000000000 +0000
@@ -885,6 +885,25 @@ The following two directories have the s
       if (! hash_insert (active_dir_map, new_ent))
        xalloc_die ();
     }
+#elif defined(D_TYPE_IN_DIRENT) && !defined(D_INO_IN_DIRENT)
+  /* DJGPP CVS supports the d_type field in struct dirent, but not d_ino.
+   * The fspec_init_dp function will therefore set the has_filetype_mode
+   * field in `fs', but leave the other fields blank. Later uses
+   * of the fspec_get_filetype_mode function will therefore not complete
+   * the device fields in `fs'.
+   *
+   * The remove_dir function expects the device information to be complete.
+   * So, we complete it here.
+   */
+  if (S_ISDIR (filetype_mode))
+    {
+      if (fspec_get_device_number (fs))
+       {
+         error (0, errno, _("cannot stat %s"),
+                quote (full_filename (fs->filename)));
+         return RM_ERROR;
+       }
+    }
 #endif
 
   if (!S_ISDIR (filetype_mode) || x->unlink_dirs)