Random data corruption with USB mass storage on 7.0-BETA2
Heiko Wundram (Beenic)
wundram at beenic.net
Thu Nov 15 23:56:24 PST 2007
Am Donnerstag, 15. November 2007 20:34:57 schrieb Dennis Melentyev:
> You need to check is it FAT12 or FAT16 on a card. AFAIR fdisk can show
> this info.
It's a FAT16 when formatted by the phone software (I checked that initially),
but I can format the stick as FAT32 (by using newfs_msdos on the device) and
still have the phone accept it, but when copying to the FAT32-formatted
device random data corruption still occurs, i.e. the same problem noted in my
1) format device as FAT32 with newfs_msdos,
3) copy files,
4) unmount, (and don't plug the USB out)
6) checking files shows the metadata as being the same as before the unmount,
but the files being different.
The file corruption that occurs is similar: random, but not completely,
because the differing file content comes at (somewhat) fixed offsets in the
As I did not unplug the phone from the USB port while doing the FAT32 check
run, the phone software never got a chance to actually access the memory
stick while doing the above (Symbian blocks all accesses to the stick when
USB in file-transfer mode is active), so I should guess the corruption comes
purely from the host system.
> Had the same problem with SE 64Mb card in K750i. It turned out that SE
> creates FAT12 on a 32+Mb disk, which is not supposed to be an option.
The K750i is not comparable, as the W600i is UIQ-based (i.e. Symbian +
extras), whereas the K750i is not.
> PS. To just make it work - just re-format it and restore folders
> structure. But please, create a filesystem dump first, to let
> developers decide is it a fault of SE phone or MSDOSFS code.
After you talked about filesystem dumps, you got me an idea:
1) format the memory stick with the phone software
2) make a dump with dd (dd if=/dev/da0 of=disk.img bs=4k)
3) set that up as a memory disk,
4) mount that: lo and behold, the directory structure on the memory disk was
just as it is displayed in the file manager of the phone (i.e., MEMSTICK.IND
and MEMSTICK_PRO.IND were there in the root of the mount-point)
5) copy my files over to the mount point,
6) unmount the memory disk,
7) mount the memory disk, check files against the source, lo and behold, the
files were equal (i.e., not corrupted during copy),
8) unmount the memory disk,
9) remove the memory disk,
10) copy the disk image back to the phone (dd if=disk.img of=/dev/da0 bs=4k)
When I now access the memory stick from the phone (by unplugging it from USB),
the files aren't corrupt.
To finally test my hypothesis that this is a bug in the msdosfs-code, I
mounted the device directly after doing this (which had MEMSTICK.IND and
MEMSTICK_PRO.IND disappear again under the mount-point), copied some more
files over, unmounted, remounted, and the same corruption seen before
occurred again with the newly copied files (i.e., the phone software
complained about broken MP3s when unplugging the phone from USB later on).
Testing the old files (which I put on the memory stick with the above
procedure) under the mount-point against the source showed them as being not
equal, but the phone did not complain about corrupted MP3s when trying to
play them, so basically on the "real" medium the data was still intact.
If anybody wants to test with a dump of the filesystem or just more info, mail
me, and I'll set that up somewhere as a download.
For now, I'll personally try and see what changed between 6.2-STABLE and
7.0-BETA2 in the msdosfs-code that breaks this.
Product & Application Development
Office Germany - EXPO PARK HANNOVER
Beenic Networks GmbH
Mailänder Straße 2
Fon +49 511 / 590 935 - 15
Fax +49 511 / 590 935 - 29
Mobil +49 172 / 437 3 734
Mail wundram at beenic.net
Beenic Networks GmbH
Sitz der Gesellschaft: Hannover
Geschäftsführer: Jorge Delgado
Registernummer: HRB 61869
Registergericht: Amtsgericht Hannover
More information about the freebsd-stable