Weird behaviour of DagReader.Seek() when using with SEEK_END

[sahib]

Seek(0, SEEK_END) might sometimes return either the size of the stream in bytes (correct) or
0 (and io.EOF) on other occasions. I put together a minimal working example here:

https://gist.github.com/sahib/4363c36dc2352d1fba7634fd46eb7978

Steps to reproduce:

# Build the testcase:
$ curl -L http://tiny.cc/yo5tay > ipfsbug.go
$ go build ipfsbug.go

# Create a 257KB big file with all zeroes and throw it into ipfs
$ export HASH_257=`dd if=/dev/zero bs=1K count=257 2>/dev/null | ipfs add -q`
$ ./ipfsbug -repo ~/.ipfs -hash $HASH_257
263168 <nil>   
263167 <nil>
1 <nil>
0 EOF            # This should be the same as the first line.

# For files <= 256K it still seems to work (256K == chunksize?):
$ export HASH_256=`dd if=/dev/zero bs=1K count=256 2>/dev/null | ipfs add -q` 
$ ./ipfsbug -repo ~/.ipfs -hash $HASH_256
262144 <nil>
262143 <nil>
1 <nil>
262144 <nil>

Another oddity: ipfs seems to use a positive offset for going back from SEEK_END, while other implementation usually use negative offsets to go back from the end and positive to extend above the file limits. Example:

// ipfs semantics: Go back one byte from the end...
r.Seek(1, os.SEEK_END)
// ...but usually you'd expect this:
r.Seek(-1, os.SEEK_END)

I failed to find a good reference that suggests that behaviour,
but the go docs say this about SEEK_END:

const (
        SEEK_SET int = 0 // seek relative to the origin of the file
        SEEK_CUR int = 1 // seek relative to the current offset
        SEEK_END int = 2 // seek relative to the end
)

...where relative to (hopefully) should mean the same direction for all whences.
This should be easy to change, since (after a quick look) ipfs only ever uses Seek(0, SEEK_END).

[whyrusleeping]

@sahib good catch there. I definitely had a misunderstanding as to the argument to SEEK_END

[magik6k]

This was fixed in ipfs/go-unixfs#60