Hi,
This is yet another report from FiSC :) This time FiSC complains that
sync on msdos and vfat doesn't flush everything out. Crash after sync
still causes data loss.
Test cases and crashed disk images can be found at
http://fisc.stanford.edu/bug8 (msdos)
http://fisc.stanford.edu/bug11 (vfat)
Confirmations/clarifications are apprecitaed.
-Junfeng
Junfeng Yang <[email protected]> writes:
> Test cases and crashed disk images can be found at
> http://fisc.stanford.edu/bug8 (msdos)
> http://fisc.stanford.edu/bug11 (vfat)
vfat and msdos doesn't support the link(), and the truncate() which
extends size is not supported yet.
This test seems to calling abort(0) by CHECK(ret)...
--
OGAWA Hirofumi <[email protected]>
> vfat and msdos doesn't support the link(), and the truncate() which
> extends size is not supported yet.
>
> This test seems to calling abort(0) by CHECK(ret)...
I updated the test case (basically just set CHECk to be a NOP). Can you
please download and re-run the test case? After reboot, run dosfsck -a on
the crashed disk, you'll see some output like:
dosfsck 2.10, 22 Sep 2003, FAT32, LFN
/?004 and
/0005
share clusters.
Truncating second to 0 bytes.
/0005
File size is 4 bytes, cluster chain length is 0 bytes.
Truncating file to 0 bytes.
Performing changes.
/dev/sbd0: 5 files, 4/8167 clusters
This causes file /0005 to be truncated to 0.
-Junfeng
Junfeng Yang <[email protected]> writes:
> /?004 and
> /0005
> share clusters.
> Truncating second to 0 bytes.
> /0005
> File size is 4 bytes, cluster chain length is 0 bytes.
> Truncating file to 0 bytes.
> Performing changes.
> /dev/sbd0: 5 files, 4/8167 clusters
>
> This causes file /0005 to be truncated to 0.
The 0004 seems to be already deleted directory actually, because first
char is 0xE5 (0xE5 is deleted mark).
Please download fixed dosfsck
http://user.parknet.co.jp/hirofumi/tmp/fatfsprogs.tar.bz2
--
OGAWA Hirofumi <[email protected]>