Random data corruption with USB mass storage on 7.0-BETA2

[Heiko Wundram (Beenic)]

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 
last mail:

1) format device as FAT32 with newfs_msdos,
2) mount,
3) copy files,
4) unmount, (and don't plug the USB out)
5) mount,
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 
files.

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.

-- 
Heiko Wundram
Product & Application Development
-------------------------------------
Office Germany - EXPO PARK HANNOVER
 
Beenic Networks GmbH
Mailänder Straße 2
30539 Hannover
 
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