Hi,
Przemysław Czerpak wrote:
memo file size and block offset. For relatively small memo files it may help to early detect corruption but it will not help for big files and for sure in all cases it will cause performance reduction because we will have to add additional IO call to check current file size. To reduce the overhead we can add such verification only for blocks bigger then some arbitrary chosen by us limit i.e. 4MB. If you think it's worth to implement then I can do that.
Since this is not the first and only time we have such situation, I found it useful. It could be even bigger limit, ex., 16MB or more, but should be less than OS available memory size - otherwise app is halted. Adaptive algorithm that stores FPT size in memory and rechecks file size if this block size is larger than this value is the best solution, but I this requires FPT AREA structure change, etc.
The other solution could be reading not the whole block, but beginning of it (if it is very big). If block has a huge size, perhaps, a few other bytes (like field type) in the beginning of the block will show that field is invalid. (I do not know fpt stucture, so, this is only guess).
I can also enable strict TYPE verification but it may cause problems when some extended types stored by program compiled by other languages are used. There are many local extensions to FPT format. Now Harbour returns NIL for such fields.
This could be useful to detect extended FPT files and implement such extensions in Harbour.
Regards, Mindaugas _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
