WriteFile bug about script

[bitfield]

Thanks! I'm sure you're right. The weird thing is, this works as expected on MacOS. I don't know enough about the respective kernels to know why this would be, but adding O_TRUNC to the flags doesn't change the behaviour at all. If it fixes your problem on Windows, I see no reason not to make this change. I'll run up a PR for it.

[lyderic]

Hi John,

I confirm that the fix works for me (Linux Arch, go 1.17.5, 'fix_truncate_bug_81' branch).

Many thanks for the fix.

Cheers,
Lyderic

[lyderic]

I don't think that it's a Windows only problem. I am on Linux (ubuntu LTS 20.04, kernel 5.11, go 1.17.1) and I have the same behaviour as the OP.

Example program to reproduce:

package main

import (
        "github.com/bitfield/script"
)

func main() {
        script.Echo("abcdef").WriteFile("foo")
        script.Echo("bar").WriteFile("foo")
        script.File("foo").Stdout()
}

The output of the program is 'bardef', whereas I would expect the output to be 'bar'.

Many thanks for looking into this and also many thanks for the script library!

[bitfield]

It must be working accidentally because I've only been able to test it on macOS, then! Thanks for the report @lyderic.

[bitfield]

This isn't a macOS issue, just me being dumb. The test for WriteFile didn't actually test that it truncates the file, only that it successfully creates a new one. I added a TestWriteFileTruncatesExisting, which writes a bunch of zeroes to the file, and then calls WriteFile with slightly fewer bytes. If there are still zeroes left at the end of the file, then the truncating hasn't worked.

This fails as expected on my macOS system, so I've added the O_TRUNC flag as suggested. This passes the test for me.

@lyderic and @badrelmers, would you mind testing my candidate fix in 1c76e65? If it passes tests and runs your example programs correctly, then we're all good. Many thanks for the report.