I just want to say, that I've seen and produced a truckload of Go code, and the overall code quality of this library is very, very good!

A few highlights:

• The code is self-documenting,
• The package structure is sensible, e.g. boot sector stuff in own package
• I would've had to build a "fragment reader" myself, but you had it ready. It was a joy. :)
• Where you saw fit to add comments, they were truly for need like this line

  gomft/mft/mft.go

  Line 378 in f64df39

  // fragment.Reader). Note that data will probably not align to a cluster exactly so there could be some padding at the

  (when I saw that I immediately realized what the bug in my software was)

Good job! You rock.

Sorry to spam issue tracker, I couldn't find other contact details :)

• in "padTo" function , I don't get the point of filling 0xff to the return value. maybe you should jsut remove it

func ParseDataRuns(b []byte) ([]DataRun, error) {
	...
	dataLength := binary.LittleEndian.Uint64(padTo(lengthBytes, 8))
	....
	dataOffset := int64(binary.LittleEndian.Uint64(padTo(offsetBytes, 8)))
}

func padTo(data []byte, length int) []byte {
        ..... 
	if data[len(data)-1]&0b10000000 == 0b10000000 {
		for i := len(data); i < length; i++ {
			result[i] = 0xFF
		}
	}
	return result
}

go run .\gomft.go
bug info

github.com/t9t/gomft/mft

E:\go\src\github.com\t9t\gomft\mft\mft.go:407:24: syntax error: unexpected b10000000, expecting {
E:\go\src\github.com\t9t\gomft\mft\mft.go:408:3: syntax error: unexpected for, expecting expression
E:\go\src\github.com\t9t\gomft\mft\mft.go:412:2: syntax error: non-declaration statement outside function body

@t9t

Thank you for sharing the code of this library. As a newbie to MFT, could you write an example? I would greatly appreciate it if you could read the $MFT file directly without copying it, and then parse out the file name of each file.

hello!, i've experienced some issues while trying to read the $FILE_NAME attribute, it just doesn't send me any character and remains with 0 data in the whole $MFT

C:\Users\Lucas\Documents\Golang\mfttest>main.exe C:\Users\Lucas\Downloads\MFTECmd\xd.jaja
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0

package main

import (
   "errors"
   "fmt"
   "io"
   "log"
   "os"

   "github.com/t9t/gomft/mft"
)

func main() {
   f, err := os.Open(os.Args[1])
   if err != nil {
   	log.Fatalln("Unable to open file", err)
   }
   defer f.Close()

   recordSize := 1024
   for {
   	buf := make([]byte, recordSize)
   	_, err := io.ReadFull(f, buf)
   	if err != nil {
   		if errors.Is(err, io.EOF) {
   			break
   		}
   		log.Fatalln("Unable to read record data", err)
   	}

   	jaja, err := mft.ParseFileName(buf)
   	if err != nil {
   		continue
   	}
   	fmt.Println(jaja.Name, len(jaja.Name))

   }
}

When offsetLength is zero, it has special semantic meaning (= sparse file):

(source, see "Example 4 - Sparse, Unfragmented File")

This code decodes a sparse offset as 0, which would incorrectly read a fragment beginning from first cluster of volume (= VBR).

My initial naive idea was to mark sparse runs as having offset -1, but that's incorrect as each run's offset is relative to previous run, i.e. negative values are legal. I solved this issue in my code by making the offset a pointer to an integer, i.e. nil means it's sparse.

Directly related to this, DataRunsToFragments needs to take sparse runs into account. Data run offsets are relative previous non-sparse run, not previous run:

This assignment can only be done if current run is non-sparse. I suggest renaming the variable to e.g. previousNonSparseOffsetCluster.

Natural consequence of sparse run support is supporting sparse fragments, which I again marked as *int to discriminate between sparse and non-sparse runs. I had to re-write fragment.Reader in my project because alternating between actual disk-backed fragments vs sparse fragments would've been hackish to add without a re-write.