Hello, I am using VFS Manager APIs to work with raw binary files on the SD card. I have recently had an alarming portion of my users experience a corruption of their filesystem, however.
It tends to manifest as a corrupted directory table. A snippit of a "dir /s " on one such user's corrupted directory: 08/12/2006 03:08 AM 16,384 58.DAT 08/12/2006 03:08 AM 16,384 59.DAT 08/12/2006 03:08 AM 16,384 60.DAT 08/12/2006 03:08 AM 16,384 61.DAT 08/12/2006 03:08 AM 504,022,537 N 11/18/2035 10:01 AM 1,869,181,811 urveilla.nce 01/08/2005 01:50 PM <DIR> nicians:.\n8 01/13/2006 06:49 AM 959,788,845 nprofess.ion 11/18/2029 02:43 PM 1,181,637,725 rp.\n[Ma.nuf 10/16/2032 01:50 PM <DIR> inicians.: 8 03/15/1996 02:33 PM 1,767,255,671 mond-sha.ped 11/05/2037 10:17 AM 1,936,024,434 oration\.n[M 03/01/2037 01:34 PM 1,663,989,861 ient Inf.orm 03/24/2003 12:11 PM <DIR> 866-448-.759 03/15/2037 02:03 PM 943,208,558 s:\nPage.t's Here, you can see the tail end of the first 61 of my uniformly-sized data files show up just fine (there happen to be 118 in this directory); then, the contents of the data files themselves appear to be interpreted, in err, as FAT16 directory entries! Yow. Again, I'm not doing anything low-level with slot drivers or hacksih expansion manager stuff. I'm simply using VFS Manager APIs to create, read, write, and seek into files. This code has been working fine for about a year for a very large number of Palm users, but something appears to have changed (new hardware? poorly-engineered SD cards? new OS bug?) that is now causing some grief. Has anybody else ever seen this kind of corruption? Thanks, -Jeff Ishaq Palm OS(R) Certified Developer -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
