binary.read returns "unexpected EOF" no matter what dBase (.dbf) File I use

func main() {
file, err := os.Open("example.dbf") // For read access.
if err != nil {
log.Fatal(err)
}
dBaseioReader, err := NewReader(file)
if err != nil {
log.Fatal(err)
}
return nil
}
type dbHeader struct {
Version             byte
LastUpdate          [3]byte
NumRecords          int32
NumBytesInHeader    int16
NumBytesInRecord    int16
_                   [2]byte //reserved
IncompatFlag        byte
EncryptionFlag      byte
MultiUserProcessing [12]byte
MDXProductionFlag   byte
LangDriverId        byte
_                   [2]byte //reserved
LangDriverName      [32]byte
_                   [4]byte //reserved
}
type dbFieldDescriptor struct {
FieldName         [32]byte
FieldType         byte
FieldLen          byte
FieldDec          byte
_                 [2]byte
MDXProductionFlag byte
_                 [2]byte
NextAutoIncrement [4]byte
_                 [4]byte
}
type DBaseReader struct {
rawInput *bufio.Reader
Header   *dbHeader
Fields   []*dbFieldDescriptor
recordsLeft int
}
func NewReader(input io.Reader) (dbr *DBaseReader, err error) {
dbr = &DBaseReader{
rawInput: bufio.NewReaderSize(input, 32*1024),
Header:   &dbHeader{},
}
err = binary.Read(dbr.rawInput, binary.LittleEndian, dbr.Header)
if err != nil{
return
}
dbr.recordsLeft = int(dbr.Header.NumRecords)
headerBytesLeft := dbr.Header.NumBytesInHeader
headerBytesLeft -= dbHeaderSize
// read field descriptors until 0x0D termination byte
var term []byte
for {
field := &dbFieldDescriptor{}
err = binary.Read(dbr.rawInput, binary.LittleEndian, field)
if err != nil{
//FIRST CRASH HAPPENS HERE.
return
}
dbr.Fields = append(dbr.Fields, field)
headerBytesLeft -= dbFieldDescriptorSize
// check for terminator byte
term, err = dbr.rawInput.Peek(1)
if err != nil{
return
}
if term[0] == 0x0D {
break
}
}
// read the terminator
_, err = dbr.rawInput.ReadByte()
if err != nil {
return
}
headerBytesLeft -= 1
if headerBytesLeft > 0 {
err = fmt.Errorf("Error: Header Bytes Left: %d.. Read Properties?!..\n", headerBytesLeft)
return
// headerLeftOver := make([]byte, headerBytesLeft)
// err = binary.Read(dbr.rawInput, binary.LittleEndian, headerLeftOver)
// if err != nil {
// 	return
// }
// props := &dbFieldProperties{}
// err = binary.Read(dbr.rawInput, binary.LittleEndian, props)
// if err != nil {
// 	return
// }
// fmt.Printf("Props: %#v\n", props)
}
// read until first record marker
_, err = dbr.rawInput.ReadBytes(' ')
if err != nil {
return
}
return dbr, nil
}

Above is the relevant code. Program crashes no matter what example dbf file I use. I'm not sure why I keep getting "Unexpected EOF" error. I've been trying to figure this out over the past few days with no luck unfortunately.

You have provided no evidence that your file format is correct. Before you wrote your program, you should have confirmed that you have the correct format for the file.

What are the first 256 bytes of the file? For example,

hex.go:

package main
import (
"encoding/hex"
"fmt"
"io/ioutil"
"os"
"strconv"
)
func main() {
if len(os.Args) <= 1 {
fmt.Fprintln(os.Stderr, "usage: hex filename [bytes]")
return
}
data, err := ioutil.ReadFile(os.Args[1])
if err != nil {
fmt.Fprintln(os.Stderr, "filename:", err)
return
}
n := len(data)
if len(os.Args) > 2 {
i, err := strconv.Atoi(os.Args[2])
if err != nil {
fmt.Fprintln(os.Stderr, "bytes:", err)
return
}
if n > i {
n = i
}
}
fmt.Print(hex.Dump(data[:n]))
}

Output:

$ go run hex.go example.dbf 256
00000000  03 01 04 18 01 00 00 00  41 07 d0 05 00 00 00 00  |........A.......|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 03 00 00  |................|
00000020  54 52 41 43 4b 5f 49 44  00 00 00 43 01 00 00 00  |TRACK_ID...C....|
00000030  0b 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  4c 4d 55 4c 54 00 00 00  00 00 00 4c 0c 00 00 00  |LMULT......L....|
00000050  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  4e 54 41 58 59 45 41 52  00 00 00 4e 0d 00 00 00  |NTAXYEAR...N....|
00000070  04 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  4e 43 4f 55 4e 54 59 43  4f 44 00 4e 11 00 00 00  |NCOUNTYCOD.N....|
00000090  02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  43 50 52 4f 50 41 44 44  00 00 00 43 13 00 00 00  |CPROPADD...C....|
000000b0  3c 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |<...............|
000000c0  4c 43 4f 4d 4d 49 4e 44  00 00 00 4c 4f 00 00 00  |LCOMMIND...LO...|
000000d0  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  4c 56 41 43 4c 41 4e 44  00 00 00 4c 50 00 00 00  |LVACLAND...LP...|
000000f0  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
$

> The table level
>
> But what is the level of a table? The level means its version. The
> dBASE table format is a standard that has evolved over time. When a
> new version of dBASE made some improvements to that format, a new
> format level number was given, identical to the new dBASE version. For
> example, we have levels 3, 4, 5 and 7 corresponding to dBASE III,
> dBASE IV, dBASE 5, and Visual dBASE 7. There is no level 6 because
> there was no Visual dBASE 6.
>
> Level 7 brought many improvements. The field names can have up to 31
> characters (from a maximum of 10 before). Some new fields types have
> appeared (for example, the AutoIncrement field that makes nearly
> impossible to give the same number to two records in the same table).
> If your tables have to be used by other software, you might have to
> sacrifice these advantages for the sake of compatibility, as few
> applications can use a level 7 table.

.dbf File Formats:

The file header byte 0, bits 0-2 indicates the version number: 3 for dBASE Level 5, 4 for dBASE Level 7.

Level 5 DOS Headers

Xbase Data file (*.dbf)

dBASE Version 7 Table File