FileSize() vs. Lof()

[nco2k]

Code: Select all

FileName.s = "C:\test.txt"
DeleteFile(FileName)
If OpenFile(0, FileName)
  WriteString(0, "test")
  FlushFileBuffers(0)
  Debug "Lof() = "+Str(Lof(0));<--- works
  Debug "GetFileSize_() = "+Str(GetFileSize_(FileID(0), 0));<--- works
  Debug "FileSize() = "+Str(FileSize(FileName));<--- returns 0
  CloseFile(0)
EndIf

FileSize() seems to return the correct value (only?) after CloseFile().

tested on PB4.02 WinXP x32 & Vista x64.

c ya,
nco2k

[Konne]

Propably Windows updates the Value after you closed the file again. (Why should it do it earlyer anyways?).

[nco2k]

i doubt this has something to do with windows itself, since the api works. after flushing the buffers, the correct size should be returned imho. i dont see any reason why it shouldnt.

c ya,
nco2k

[freak]

It is definately a Windows thing.

Modern filesystems do their own caching.
That a value the size of 4bytes is not immediately written to disk makes a lot of sense.

[netmaestro]

I doubt this has something to do with windows itself, since the api works

Not so fast there. You're mixing apples and oranges. That api is working with a filehandle which by definition assumes a currently-opened file. That it is up-to-date would be expected here. The native FileSize() call is looking on the disk for a filename and is expecting to work with a closed file (or perhaps even a file that can't be found,) so the observed behaviour is predictable imho.

If a file is currently opened, use Lof() for accurate results. If it's not, use FileSize(). Two different tasks, each with its own tool.

Also, notice that Lof(), unlike GetFileSize_(), needs no flushing of buffers to return an accurate result as it's maintained internally.

[nco2k]

@freak
well, if its a windows limitation, it cant be helped. i was just wondering, because flushing and/or disable the buffering, didnt helped at all.

c ya,
nco2k