EXT2FS Problems -- Interesting Code Snippet

[Brent Fulgham <bfulgham@xpsystems.com>]

I realized that the error message I was reporting is actually a bit
different.  Rerunning the system I see that the message is actually:

"ext2fs:  Warning:  bad type XX in directory entry: inode: YY offset: ZZ"

One of the changes made during the August update to 2.3.18-ext2fs
was:

diff -ru hurd-19990725/ext2fs/dir.c hurd-19990922/ext2fs/dir.c
--- hurd-19990725/ext2fs/dir.c	Mon Jul 12 05:31:00 1999
+++ hurd-19990922/ext2fs/dir.c	Mon Sep 13 07:12:08 1999
@@ -971,7 +987,23 @@
 	  userp->d_fileno = entryp->inode;
 	  userp->d_reclen = rec_len;
 	  userp->d_namlen = name_len;
-	  bcopy (entryp->name, userp->d_name, name_len);+
+	  /* We don't bother to check the EXT2_FEATURE_INCOMPAT_FILETYPE
+	     flag in the superblock, because in old filesystems the
+	     file_type field is the high byte of the length field and is
+	     always zero because names cannot be that long.  */
+	  if (entryp->file_type < EXT2_FT_MAX)
+	    userp->d_type = ext2_file_type[entryp->file_type];
+	  else
+	    {
+	      ext2_warning ("bad type %d in directory entry: "
+			    "inode: %d offset: %d",
+			    entryp->file_type,
+			    dp->cache_id,
+			    blkno * DIRBLKSIZ + bufp - buf);
+	      userp->d_type = DT_UNKNOWN;
+	    }
+	  memcpy (userp->d_name, entryp->name, name_len);
 	  userp->d_name[name_len] = '\0';

So the error message we are seeing might just be due to the
new warning code added.  However, the fact that I experience
real data corruption as well as this message indicates that
we are picking up an actual error.

As a side note, shouldn't we be using memmove rather than
memcpy in the last line added (above)?  The bcopy we
are replacing correctly handles cases where the source and
destination overlap, while memcpy does not.  Perhaps you
are concerned that memmove would have a performance impact?
I suppose it is unlikely that these two regions of memory
ever would overlap.

Thanks,

-Brent