On Thu, 11 Feb 2010, Mindaugas Kavaliauskas wrote: Hi,
> few times per year we find corrupted .fpt files in databeses of our > customers. The problem is that this corruption is not detected by > driver and causes strange behavior. For example, application > hangs-up, but do not GPFs. After some tests we found, that it > "hangs-up" because it uses a huge amount of memory (ex. >= 1GB) and > OS do a lot of disk swap thus stops application and system. This > memory usage is caused by reading some memo value. Total memo file > length is not big (1MB), but corrupted .ftp blocks contains huge > size values. I've wrote some code to test for such memofields, but > it would be nice to have some corruption detection code in fpt > driver. The maximum size of single memo block in FPT format is 4GB. Any upper limit check we can introduce without reducing functionality is comparing the size of memo block with the difference between total 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. 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. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
