[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1599539] Re: 2.6.0: vvfat driver generates bad FAT ent
From: |
Kevin Wolf |
Subject: |
[Qemu-devel] [Bug 1599539] Re: 2.6.0: vvfat driver generates bad FAT entries |
Date: |
Thu, 11 Aug 2016 14:09:31 -0000 |
Thanks for looking into this, Felix. If you think that your fix to
read_directory() is ready for inclusion, please do send the patch to
both the qemu-devel and qemu-block mailing lists as Thomas suggested. As
each patch should address a single point, this can be done even while
the second problem isn't fully solved yet.
I agree that erroring out when trying to open a vvfat image on a
directory with too many entries is probably the best option. Instead of
thinking of ways to do it anyway, I'd rather suggest to look into
fixing/fully implementing FAT32 support. There are a few scary comments
in the code, so I suppose it might not yet be as stable as you'd want it
to be, but it shouldn't have the root directory limit anyway.
--
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