This is a discussion on Re: Random data corruption with USB mass storage on 7.0-BETA2 - FreeBSD ; 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 ...
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) an=
still have the phone accept it, but when copying to the FAT32-formatted=20
device random data corruption still occurs, i.e. the same problem noted in =
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 unmoun=
but the files being different.
The file corruption that occurs is similar: random, but not completely,=20
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=20
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 come=
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 +=20
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=3D/dev/da0 of=3Ddisk.img bs=3D4k)
3) set that up as a memory disk,
4) mount that: lo and behold, the directory structure on the memory disk wa=
just as it is displayed in the file manager of the phone (i.e., MEMSTICK.IN=
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, th=
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=3Ddisk.img of=3D/dev/da0 b=
When I now access the memory stick from the phone (by unplugging it from US=
the files aren't corrupt.
To finally test my hypothesis that this is a bug in the msdosfs-code, I=20
mounted the device directly after doing this (which had MEMSTICK.IND and=20
MEMSTICK_PRO.IND disappear again under the mount-point), copied some more=20
files over, unmounted, remounted, and the same corruption seen before=20
occurred again with the newly copied files (i.e., the phone software=20
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=20
procedure) under the mount-point against the source showed them as being no=
equal, but the phone did not complain about corrupted MP3s when trying to=20
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, m=
me, and I'll set that up somewhere as a download.
=46or 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=C3=A4nder Stra=C3=9Fe 2
=46on +49 511 / 590 935 - 15
=46ax +49 511 / 590 935 - 29
Mobil +49 172 / 437 3 734
Beenic Networks GmbH
Sitz der Gesellschaft: Hannover
Gesch=C3=A4ftsf=C3=BChrer: Jorge Delgado
Registernummer: HRB 61869
Registergericht: Amtsgericht Hannover
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"