[Subtitle: How the last cluster is written to (full length / data length]

Jim wrote :

>I assume that VFP writes a full cluster when it updates/writes record(s), with the exception of the last one, when I suppose that it writes only for the real data length.

This is a tough one. I don't know either, but can remark the following :

For some OSses (like Novell) it is possible to obtain not-allocated blocks (clusters). A not-allocated block is filled with nulls, of which I assume this is done at the previous freeing of the block by the OS.

When a file is looked at by means of a hex editor (I use UltraEdit), it shows the possibility of the differentation between nulls and "nothing" in the last block of the file. "Nothing" means : the file ends at the EOF marker, the last block of the file not being filled completely, and the hexeditor knowing that it can't go beyond the visible EOF marker. Nevertheless, removing the EOF marker doesn't change anything to that, hence, it is not the EOF marker causing that.

Please note that this is not about spaces (20h), but that just nothing is there anymore, while we are not at the block boundary either.

Also note that, as in my case, UtraEdit doesn't show a bytelength of the file in its header area, but what I see supposedly isn't all. IOW, there might be another header above it, or, it might be data within the FAT/NTFS/etc. itself containing that information (not to be manipulated ...).

It would be my guess that VFP just obtains the logical block as a literal copy from the disk (logically mapped), and that it just writes back this literal copy after making some adjustments anywhere in it.
Please note that the distance between a block manipulated by VFP and the "file system" should be as large as possible, in order to let the file system treat all by having no intelligence at all about the contents.

I expect the area beyond the EOF marker just to contain nulls, but that even the hexeditor won't show that.

For what it's worth, I can add the following :
When the hexeditor is used to extend the file in the area beyond what the hexeditor shows (think of "insert") all official nulls in the VFP table header are changed into spaces (20h) by UltraEdit. Originally I accepted this as some bug, but now I wonder. It can very well be that the dbf type file allows for some specially treated file header (by what ?).

Anyways, to my knowledgde it cannot be that some part of the whole I/O operation performs a transfer that is less than the logical block (length). One exception I know of : the packet from the network (protocol). That can do less, but in the end a logical complete block (length) will be formed out of the several smaller packets, all comprising of the one logical data transfer.

Again, all of the above I assume.

Peter