Gracias por su tiempo

Me explico. Yo tengo que guardar un dato de configuración. Ese dato no es siempre igual de largo con lo que si escribo en el fichero un nuevo dato más corto, aun se me guarda la parte final del dato anterior y al leerlo me da problemas. Por ejemplo:

Dato viejo: activado
Dato nuevo: parado
Al escribir en el fichero el dato nuevo obtengo: paradodo

He probado a poner un null al final del dato y con el caracter ctrl+z pero no funciona.
Tambien he leido en los comentarios lo de la funcion truncate pero no he sabido hacerla funcionar.

En el fondo esto no es un problema porque ese dato se va a cambiar en muy contadas ocasiones y me basta borrar el fichero y crear otro pero tal vez en un futuro necesite hacerlo con mucha frecuencia y me gustaria saber la manera.

Muchas gracias

no, no tiene por qué. ¿Acaso tu no borras archivos de tu disco duro y aunque los borres siguen estando ahí, es decir, que son recuperables con ciertos software? Pues aquí lo mismo. La decisión de en qué sectores se escribe en la Flash es tomada por algoritmos internos del módulo, que según me dijeron en su día (aquí si me tengo que fiar de lo que me dicen desde Siemens, ya que yo no tengo el código fuente para darle un vistazo a ver qué hace) están correctamente diseñados para tal fin.

Salu2

sinceramente no lo se. No se a nivel físico qué es lo que hace el método truncate con la memoria. Si lo averiguo te cuento.

Salu2.

no veo ningún problema al uso de RecordStore.

Salu2.

cuando hablo de machacar en ningún sitio estoy hablando de sobreescribir físicamente una posición de memoria interna de la flash, entre otras cosas, porque desde java no puedo especificar usar una determinada posición de memoria concreta dentro del FFS, de eso se encargan los algoritmos internos del módem.

Cuando hablo de machacar me refiero a los registros del archivo, no a posiciones de memoria concretas. ¿Si no porqué ahí arriba digo que el borrado se hace por sectores de 64KB? ¿Qué sentido tendría poder borrar si pudiese sobreescribir un único byte físico con 0xFF? Por otro lado te puedo decir que cuenta con algoritmos para escribir de forma homogénea toda la memoria, supongo que es lo que tú llamas desgaste parejo.

La estrategia de machacar los registros dentro de un archivo en el FFS no lo digo porque sí. Por mi trabajo estoy directamente relacionado con el personal técnico de M2M de Siemens / Cinterion, con quien trato bastante a menudo, y son ellos quienes recomiendan esa esta técnica de sobreescribir registros en ficheros en lugar de borrar ficheros y crear nuevos y te aseguro que ahorra problemas. Lo veo cada día entre quienes usan una técnica u otra, pero bueno, cada uno es libre de utilizar las técnicas que quiera, por supuesto.

Salu2.

Si quieren saber si el modem tiene dicha funcionalidad de desgaste parejo implementada deben hacer la sgte prueba. Cojan un modem nuevo y hagan un sencillo programa que en un ciclo infinito coja y escriba en una posición de memoria un número de un contador, luego lo lea, si hay match incrementa el contador y de nuevo empieza a guardar y así sucesivamente. Cuando no haya match, si el contador empezó en 0 entonces el último valor del contador que se almacenó equivale al número de veces que se logró sobreescribir la misma posición de memoria flash. Esta prueba se les va demorar por ahí 1 mes si el modem tiene desgaste parejo así que cuando hagan el programita tengan en cuenta que el modem podrá reiniciarse durante la prueba (el contador no debe empezar en 0 cada vez que el modem se reinicie, se debe cargar de flash el último valor escrito y arrancar con el valor leido).

Sí el número es mucho mayor a 100.000 (he obtenido valores de 40.000.000) significa que el modem tiene algoritmos de desgaste parejo para su memoria flash. Si éste es el caso ese modem ya ha quedado con TODA su memoria flash mala o gastada.

Yo he hecho la anterior prueba para varias marcas de modem y en todos he logrado escribir y leer un bloque de memoria de 30KBytes más de 20.000.000 de veces (veinte millones de veces).

Saludos.

Según tengo entendido cuando uno escribe en una memoria flash lo que se hace es cambiar el estado de los bits que están en 1 y ponerlos a 0. (los bits que antes estaban en 1 y que luego de la escritura siguen en 1 no se tocan).

Ej. Posición de memoria 0×100 que está en blanco osea libre para escribir. Sí está en blanco el valor de la posición asumiendo una arquitectura de 8 bits sería 0xFF (0b11111111). Si en esa posición yo escribo el valor 0×30(0b00110000) lo que se hace es cambiar el estado de los bits 0,1,2,3,6 y 7 a 0. Estos bits que se han cambiado a estado 0 NO podrán ser modificados nuevamente hasta que se realice una operación de borrado sobre esa posición de memoria. Así que lo de sobreescribir la posición de memoria flash sin haberla borrado antes si es posible pero el valor que quedará almacenado no es el deseado. De modo que de acuerdo a lo anterior y según mis conocimientos la recomendación de MACHUCAR que dan acá no es muy válida que digamos.

Saludos,

Sobre el tema hay algo a lo que estoy dándole vueltas … con la escritura afectas a los bytes que escribes PERO será de una forma mucho más continuada y en las mismas posiciones -> llevará a un degradado mucho más rápido de esas posiciones.

El problema es que se tendría que implementar un mecanismo de comprobación (grabas la información, la lees para verificar que esas posiciones siguen siendo válidas, … si no son válidas a crear otro fichero y vuelta a empezar).

Por supuesto SALVO que se disponga de un controlador de “posiciones defectuosas”.

Saludos y gracias por la respuesta.

efectivamente es distinto la grabación que el borrado por el tipo de memoria. Castigas mucho más con el borrado que con la escritura. Con la escritura sólo afectas a los bytes que escribes, con cada borrado afectas a 64KB.

Salu2.

Si los registros no tienen tamaño constante, la solución existe pero es más complicada (almacenar para cada registro su tamaño, meter separadores, …).

Saludos.

Buen post … que nos llama la atención sobre el tema que existe aunque pensemos que no nos afecta.

Mi solución pasó por retardar el tiempo lo máximo posible (30-60 minutos) y “confiar” en que los dioses sean “magnánimos”.

Para (Pedro) poder escribir en una posición aleatoria del fichero puede valer este código (ojo que no lo he probado, pues escribo al final del fichero):

com.siemens.icm.io.file.FileConnection fichero= (com.siemens.icm.io.file.FileConnection) javax.microedition.io.Connector.open(rutaFichero);
java.io.DataOutputStream dos= new java.io.DataOutputStream(fichero.openOutputStream(posicionDondeEscribir));
dos.objDataOutputStream.write( datos, inicio, tamano);

La solución que se podría dar es:
- Crear un fichero con X*ctd registros máximos a almacenar.
- En otro fichero almacenar el puntero del primer y último registro (como una lista circular). Estos datos habría que actualizarlos para cada operación.

Yo no empleé esta solución pues pensé que también castigaría la memoria Flash para cada una de las actualizaciones. Según entiendo del artículo esto no es así ¿VERDAD?, el daño viene por el borrado y no por el sobreescribir los datos.

Saludos.

Tengo dos preguntas, a ver si me puedes guiar con ellas:
- Cuando escribo en un fichero puedo hacerlo de dos maneras: o escribo desde el principio o añado al final. Cómo se hace para escribir directamente sobre el registro X?
- Cómo controlas que tienes 5000 registros en un fichero?