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 :)

@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.

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.

• 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