[Qemu-devel] [Bug 1599539] Re: 2.6.0: vvfat driver generates bad FAT entries

[felix]

The original issue turned out to be trivial. The dot and dot-dot entries
need to be the two very first entries in a non-root directory table;
however, readdir() does not guarantee that "." and ".." will be the
first items returned. When I patched read_directory() to generate "."
and ".." entries first (and also ensured that volume label entry is
generated with zero size), ScanDisk stopped complaining.

The latter issue is also easy. The FAT16 file system cannot hold more
than 512 entries in its root directory table. The vvfat driver does not
recognise this limit and tries to squeeze more entries into the table
than is normally possible. FAT-reading software doesn't seem to
appreciate it. The driver should emit a warning and refuse to generate a
FAT image altogether. (I have actually thought of a way to do it anyway,
but it will not work everywhere.)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1599539

Title:
  2.6.0: vvfat driver generates bad FAT entries

Status in QEMU:
  New

Bug description:
  The vvfat driver sometimes generates entries about which file system
  checking utilities generate complaints.

  For example, dosfsck will complain that the volume label entry has
  non-zero size. ScanDisk from Windows 9x complains about invalid dot
  (".") and dot-dot ("..") entries in directories and also about invalid
  long file name entries. MS-DOS ScanDisk also often manages to find
  "lost clusters" on the drive.

  Tangentially: qemu-img convert fat:test test.img doesn't seem to work
  -- it generates an 504MiB of zero bytes and hangs. qemu-img map
  fat:test generates an assertion failure. Having qemu-img working might
  have helped with debugging the above issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1599539/+subscriptions