I recently tried to use os.Truncate with a parameter of 0 to clear a file's contents before rewritting a modified version into it (I know that it is a very unsafe practice, but the file's contents are not important to me).
The thing that shocked me is that Truncate did not reset the file's cursor, so when I wrote back to the file I ended up with a file prefixed with a bunch of null bytes (corresponding to the size of the previous contents), unless I used file.Seek(0, 0) beforehand.
So my question is: is that a bug of the language, something that was forgotten during the implementation of that function, or is it on purpose and it is a desired behaviour for some mysterious reason ? What could possibly be that mysterious reason ?
I'm using go version go1.3.3 linux/amd64
This is desired behaviour: the Go implementation mimics how the C works*. From the man page for ftruncate(2):
The file offset is not changed.
* Technically, this is because the Go implementation executes the ftruncate(2) syscall.