Random data corruption with USB mass storage on 7.0-BETA2
dennis.melentyev at gmail.com
Fri Nov 16 12:53:21 PST 2007
Yes, you really have different issue. From now on, I have no more
ideas. Hope you'll find the root of the problem.
2007/11/16, Heiko Wundram (Beenic) <wundram at beenic.net>:
> 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
> 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
More information about the freebsd-stable