Fabio,
>
>The filesize listed in the Windows Explorer, and adir() and a DIR command run in a DOS command prompt are simply displaying a filesize value as currently recorded by the directory entry. The directory entry is not updated as every cluster of disk is allocated for a file.
>>
>a) Where you found this information ? Give me a link.
Sorry, I can't give you a link to knowledge I gained in the mid 80's while working on disk recovery utilities and realtime data acquisition systems where getting data committed to disk as soon as possible was critical to the system. You should be capable of doing your own googling of the internet or picking up some books on various O/S file subsystems, I won't recommend any in particular because you probably just question their authority on the subject.
But here is experimental proof that what I stated before is true.
1) start VFP twice on the same machine
2) in the session1 command window:
create table test ( i1 i, c1 c(100) )
index on i1 tag i1
index on c1 tag c1
use
now you have an empty table, according to adir() or explorer will report a minimal filesize for the dbf and cdx, but we have to do this to allow simultaneous access to the table from both VFP sessions
3) in both VFP sessions:
use test shared
4) in session1
for i = 1 to 10
insert into test values ( i, replicate( str( i ), 10 ) )
adir( laX, "test.*" )
? laX[1,2], laX[2,2]
endfor
the filesizes according to adir() have remained static the entire time, but the data itself
5) in session2
locate for i1 = 6
The record is quite successfully located
set order to i1
seek 10
the record is found via the cdx, no flushing required from inside VFP itself.
On my system under NTFS with write caching enabled on the volume, it appears that the O/S will under idle time go back and update the directory entry, because polling it with adir() sometime later will return 5632 & 1411 which will be the size once the file is closed. I currently do not have a FAT16 or FAT32 drive to test this background directory update on.
But the directory update is irrelevant to the question posted by the originator of the thread. The data is available in the DBF and the CDX as it is inserted and does not depend on the filesize indicated by the directory.
>b) If i want the true filesize, what I must make?
You must simply close the file, which causes the O/S to update the directory entry for the file.
If you still don't believe me, ask yourself the question, based on the fact that head seek time and rotational latency are several orders of magnitude slower than disk write, and that the directory entry, file allocation chains and file data are stored in seperate physical locations on the disk, does it make much sense from a performance standpoint that every disk write operation cause the directory entry to be updated? Or in an even worse case scenario that you desire, that after every byte is written to the file the directory entry be updated? No it does not.
