On Sun, Aug 24, 2008 at 11:28:42AM +0100, Jan van Wijk wrote:
> >Hmm, looking at what you sent me, it looks like DFSee was being
> >"clever". It looks like it deliberately put something which looks
> >like almost exactly like a FAT12/FAT16 header, passing all of the
> >normal checks one might make for seeing if the various fields make
> >sense.
>
> Those fields contents (similar to FAT) are actually standard for
> any JFS filesystem formatted by the OS/2 FORMAT command
> (or rather UJFS.DLL on an OS/2 or eComStation system :-)
Thanks, that's useful information. The filesystem in question was
almost certainly created by a Linux user who didn't use OS/2 to format
his partition --- and /sbin/mkfs.jfs zeros out the 32k of the
filesystem to avoid confusion by filesystem identification programs
like blkid, vol_id, disktype, et. al.
And while I do care about making blkid be able to support ancient
filesystems for obsolete operating systems (and the
file-system-sampler from disktype.cvs.sourceforge.net has an excellent
set of filesystem exemplars for testing, including an Atari ST floppy
and a BeOS BFS filesystem), the primary goal is to be able to detect
filesystems that are likely to be used by Linux users --- so I've only
seen this situation with this pseudo FAT12/16 header with DFSee.
Maybe there are other partition management programs that cause this,
but I've not seen it in my experience.
> >The reason why I don't just check ms_magic is that there have been
> >some (badly behaved) FAT filesystem formatters which don't set
> >ms_magic, or set it to some garbage value other than "FAT12 " or
> >"FAT16 ".
>
> OK, understand, but you may see the same 'FAT like fields' for OS/2
> formatted JFS filesystems with a ms_sysid of 'IBM 4.50' ...
>
> Actually, bootsectors for an HPFS filesystems look very much like
> these as well, so you may see a similar behaviour there too.
Hmm, so maybe what I should do is put in an explicit check for "JFS "
and "HPFS " in the ms_magic field (at offset 0x36) and fail it as a
FAT filesystem if I see those magic values there. That should cover
the situation with OS/2 formatted filesystems.
Out of curiosity, does DFSee try to do something similar with any
other filesystems? Or is this something you only did for JFS and HPFS
to replicate what OS/2 was doing?
> I assume your code (that analyses the bootsector) does take into
> account that the 'ms_magic' field on FAT32 is at a different offset ?
> It is at 0x36 for FAT16 (and others) but at 0x52 for FAT32
Oh yes, e2fsprogs definitely checks for "FAT32 " and "MSWIN" at offset
0x52.
One of the things which confused me is why DFSee (and OS/2,
apparently, according to your reports) is using a FAT12/16 style
pseudo-superblock, and not a FAT32 style superblock. I also wonder
what programs were actually looking at the FAT12/16-style pseudo
superblock information for JFS and HPFS filesystems, since clearly
Linux doesn't need it, and as far as I know the MBR boot sector
doesn't require it to be present.
In any case, thanks, Jan, for your comments, they have been very
helpful!
- Ted
P.S. Here's the new version of the patch which I've applied to blkid.
commit 78d89cda680498957e4ad78602751d1f905cee08
Author: Theodore Ts'o <[EMAIL PROTECTED]>
Date: Sat Aug 23 22:11:01 2008 -0400
libblkid: Fix false detection of DFSee created filesystems.
OS/2 and DFSee creates 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 explicitly test for "JFS " and "HPFS " in ms_magic,
and if they are found, we assume the filesystem is definitely not
a FAT filesystem.
Addresses-Launchpad-Bug: #255255
Signed-off-by: "Theodore Ts'o" <[EMAIL PROTECTED]>
diff --git a/lib/blkid/probe.c b/lib/blkid/probe.c
index e2d8a25..225116a 100644
--- a/lib/blkid/probe.c
+++ b/lib/blkid/probe.c
@@ -566,25 +566,38 @@ static int probe_fat_nomagic(struct blkid_probe *probe,
struct blkid_magic *id __BLKID_ATTR((unused)),
unsigned char *buf)
{
- struct vfat_super_block *vs;
+ struct msdos_super_block *ms;
- vs = (struct vfat_super_block *)buf;
+ ms = (struct msdos_super_block *)buf;
/* heads check */
- if (vs->vs_heads == 0)
+ if (ms->ms_heads == 0)
return 1;
/* cluster size check*/
- if (vs->vs_cluster_size == 0 ||
- (vs->vs_cluster_size & (vs->vs_cluster_size-1)))
+ if (ms->ms_cluster_size == 0 ||
+ (ms->ms_cluster_size & (ms->ms_cluster_size-1)))
return 1;
/* media check */
- if (vs->vs_media < 0xf8 && vs->vs_media != 0xf0)
+ if (ms->ms_media < 0xf8 && ms->ms_media != 0xf0)
return 1;
/* fat counts(Linux kernel expects at least 1 FAT table) */
- if (!vs->vs_fats)
+ if (!ms->ms_fats)
+ return 1;
+
+ /*
+ * OS/2 and apparently DFSee will place a FAT12/16-like
+ * pseudo-superblock in the first 512 bytes of non-FAT
+ * filesystems --- at least JFS and HPFS, and possibly others.
+ * So we explicitly check for those filesystems at the
+ * FAT12/16 filesystem magic field identifier, and if they are
+ * present, we rule this out as a FAT filesystem, despite the
+ * FAT-like pseudo-header.
+ */
+ if ((memcmp(ms->ms_magic, "JFS ", 8) == 0) ||
+ (memcmp(ms->ms_magic, "HPFS ", 8) == 0))
return 1;
return probe_fat(probe, id, buf);
--
blkid library detects JFS partition as FAT32
https://bugs.launchpad.net/bugs/255255
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
