WriteFile is broken on Windows

[dhaavi]

I've read a couple issues on Windows support, and I'm not sure what the current support state is.

Anyway, the WriteFile function is broken on Windows, as *os.File.Chmod() used in the function is not supported on Windows:

renameio/writefile.go

Line 29 in a368f99

if err := t.Chmod(perm); err != nil {

[twpayne]

It does not seem possible to do atomic file replacement on Windows, see the discussion in #1.

If you want a chmod function that works on Windows, consider https://github.com/hectane/go-acl/blob/master/chmod.go#L14 (more recent version at https://github.com/twpayne/go-acl/blob/chezmoi/chmod.go#L14).

[dhaavi]

I also just noticed that these other referenced issues belong to another project: twpayne/chezmoi
I guess that caused some confusion here.

While not being atomic, it would still be better than just writing files directly, wouldn't it?

I don't care about chmod other than it breaking Windows compatibility.

[twpayne]

The first link is to hectane/go-acl. This library has a pending pull request (hectane/go-acl#14) that improves Windows support. The second link is to a friendly fork that includes that PR.

[dhaavi]

I think I did a poor job communicating what I am trying to achieve here.

In my case, I don't care about the chmod call, but want the library working.

Do you want to "fix" WriteFile by just leaving out the chmod call on Windows? As far as I understand, this is also how many Go std utils work: You give them permissions via os.FileMode, but they are actually only used on POSIX systems.

Or, do you want to let WriteFile broken as is on Windows until you find a real fix? Then I'd just remove the chmod call myself for the few times I need it.

[stapelberg]

I don’t do Windows development, so I’ll rely on a pull request containing a fix. Thanks in advance :)

[andhe]

Ok, so apparently f.Chmod(perm) errors out on windows as the syscall is not available but os.Chmod(filename, perm) does not error! Maybe we can just change the code to use the latter (with t.Name() as filename) ...

[twpayne]

This issue is (arguably) fixed by #20. It may be worth re-opening #1 for when Windows supports atomic file operations.