Comment 6 for bug 255255

FYI, this is what I've checked into the e2fsprogs git repository.

                                    - Ted

commit 8305cdf401b05e3748b87d0b63c4fa5bad8f8eb6
Author: Theodore Ts'o <email address hidden>
Date: Sat Aug 23 22:11:01 2008 -0400

    libblkid: Fix false detection of DFSee created filesystems.

    DFSee appears to create a pseudo FAT-12/16 header in the first 512
    bytes of a filesystem which looks enough like a FAT-12/16 to fool
    blkid. Part of this is because we don't require ms_magic or vs_magic
    to be the strings "FAT12 ", "FAT16 ", or "FAT32 ", since some FAT
    filesystem formatters don't set ms_magic or vs_magic. To address
    this, we add an explicit test for DFSee in the ms_sysid field, and if
    ms_sysid has a DFSee signature, then we require the ms_magic/vs_magic
    fields to be filled in appropriately.

    Signed-off-by: "Theodore Ts'o" <email address hidden>

diff --git a/lib/blkid/probe.c b/lib/blkid/probe.c
index e2d8a25..31f3c74 100644
--- a/lib/blkid/probe.c
+++ b/lib/blkid/probe.c
@@ -587,6 +587,20 @@ static int probe_fat_nomagic(struct blkid_probe *probe,
  if (!vs->vs_fats)
   return 1;

+ /*
+ * The DFSee product apparently creates a FAT12-like boot
+ * block for non-FAT filesystems. It seems to do this at
+ * least for JFS (see Launchpad Bug #255255) and possibly
+ * others. We already check for the FAT12/16/32 magic strings
+ * in the probe table, so if we got here, it must be because
+ * we have something created by DFSee but which isn't actually
+ * a FAT filesystem. I'm assuming here that DFSee actually
+ * does fill in ms_magic and vs_magic correctly, but that
+ * seems like a safe bet.
+ */
+ if (memcmp(vs->vs_sysid, "DFSee", 5) == 0)
+ return 1;
+
  return probe_fat(probe, id, buf);
 }