Author Topic: End Of File  (Read 4440 times)

Offline neil

  • Sr. Member
  • ****
  • Posts: 433
    • View Profile
End Of File
« on: November 13, 2013, 05:09:14 PM »
Hi Mark
  I want to detect the eof condition after a read command (also before) do I simply check if the UTFILE.uFilePosition == UTFILE.uFileSize?  

  And if the both are the same, will a seek to the end place the file position at the same place, or 1 space after?

  I want to make sure if I read through a file until I get to the end (as above), and start writing, this is the same as doing a utSeek(&fd, 0, UTFAT_SEEK_END); , then start writing.

« Last Edit: November 13, 2013, 05:12:42 PM by neil »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3187
    • View Profile
    • uTasker
Re: End Of File
« Reply #1 on: November 13, 2013, 06:07:36 PM »
Hi Neil

When you have read to the end of a file it is true that
UTFILE.uFilePosition == UTFILE.uFileSize
whereby it is to be noted that UTFILE.uFilePosition is like an index in an array and so is 'pointing' to the next free element of the array and not the last byte in the array. This means that it is effectively pointing to the element that will be used for the next written byte if writes were to be made at this location in the file. [Of course the content is not actually stored as an array since it can be spread out in clusters all over the card but the analogy holds when looked at from the user interface].

If you try to read more content than exists you can also detect that the end of the file has been reached because UTFILE.usLastReadWriteLength will be less that the length requested.

utSeek(&fd, 0, UTFAT_SEEK_END); will advance the file pointer to the end of the file just as reading all of the content does, therefore UTFILE.uFilePosition == UTFILE.uFileSize is also valid after the seek.

This means that if you have read all file content and know that you are at the end of the file there is no need to seek to the end of it to start adding more data. Actually calling the seek in this instance will however be very low overhead since it will immediately detect that it is already at the location requested and return after just a few instructions (it won't cause it to physically seek from the start of the file to the end again).