> So the next question is "What does Plucker look at > when it's enumerating files during an update > operation?"
It loops through the files in the directory opening the files, accessing the database info (e.g. the type and creator ID) and it checks the returned error code when available. If the *OS* crash when you try to open a corrupt file then there is nothing Plucker can do about it. Palm OS is quite robust, but it has some very bad parts, too, e.g. there is a function called DmWriteCheck that according to the API docs could be used to check the parameters for a write operation (bad input parameters to DmWrite will result in a fatal error). However, if you provide the DmWriteCheck function with "bad" parameters it will also crash with a fatal error... > If Plucker needs anything, it may be more robust > error handling when it runs into a bad file. It has a quite robust error handling; some parts can probably be improved, but the enumerate code is not one of those parts. Also, if the OS crash instead of returning an error code there is no error for Plucker to "handle" ;-) > unfortunately too likely for FAT formatted expansion > cards. I have never had any problems with the CF card in my TRGpro, so either I have been very lucky or the TRGpro's CF handling is of a higher quality than the Visor's CF implementation (after all on the TRGpro it is built-in and not a later add-on.) /Mike _______________________________________________ plucker-list mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-list
