去os.Truncate（）不重置文件光标

Question

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

Answer 1

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.