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 [EMAIL PROTECTED] Beenic Networks GmbH ------------------------------------- Sitz der Gesellschaft: Hannover Geschäftsführer: Jorge Delgado Registernummer: HRB 61869 Registergericht: Amtsgericht Hannover _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
