@bep I'm sorry if I've caused you additional, unnecessary work, but I hope you can appreciate how "chtimes fails on FAT32" as a bug report is vastly different from asking "why is there a colon in the error message of this software I am using".

I did not close the original issue because it was referred from Hugo, I closed it because it provided no useful information, had a straightforward answer to the asked question, and made no indication that it was originally filed elsewhere. Rather, it looked like one of many instances of "I'm using a program written in Go and it displays an error I don't understand". I'm sure you can see that such a description doesn't imply a bug in Go itself, and rather looks like difficulty in using some software written in Go. And it is natural to refer users to the issue tracker of the software they are having difficulty with.

And, of course, to be remotely able to debug this issue, the user needs to fill in the issue template, and provide a minimal example that reproduces the issue. Which implies they need to be able to write and run Go code. They also need to dig into Hugo to figure out how exactly it is calling chtimes.

@bep I have no idea what your problem is, because you did not explain. So I just tried few things.

In particular we have TestChtimes test in os package. And it tests os.Chtimes. I inserted USB flash disk into my computer (as D: drive), and then did this

C:\>set TMP=D:\temp

C:\>set TEMP=D:\temp

C:\>test -test.v -test.run=TestChtimes$
=== RUN TestChtimes
--- FAIL: TestChtimes (0.05s)
    os_test.go:1178: AccessTime didn't go backwards; was=2019-07-31 00:00:00 +1000 AEST, after=2019-07-31 00:00:00 +1000 AEST
    os_test.go:1183: ModTime didn't go backwards; was=2019-07-31 05:31:42 +1000 AEST, after=2019-07-31 05:31:42 +1000 AEST
FAIL

C:\>

So the TestChtimes indeed fails when FAT is used.

But os.Chtimes uses Windows API SetFileTime to implement whatever it does. And according to https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfiletime

Not all file systems can record creation and last access times and not all file systems record them in the same manner. For example, on FAT, create time has a resolution of 10 milliseconds, write time has a resolution of 2 seconds, and access time has a resolution of 1 day (really, the access date).

And, indeed, if I change TestChtimes

diff --git a/src/os/os_test.go b/src/os/os_test.go
index c101281258..c01f4d8f94 100644
--- a/src/os/os_test.go
+++ b/src/os/os_test.go
@@ -1144,7 +1144,7 @@ func testChtimes(t *testing.T, name string) {
  // Move access and modification time back a second
  at := Atime(preStat)
  mt := preStat.ModTime()
-	err = Chtimes(name, at.Add(-time.Second), mt.Add(-time.Second))
+	err = Chtimes(name, at.Add(-2*time.Second), mt.Add(-2*time.Second))
  if err != nil {
   t.Fatalf("Chtimes %s: %s", name, err)
  }

it passes. So it is hit and miss when you use FAT.

Let me know, if you want us to do anything else for this issue.

Thank you.

Alex

sound good like a solution :-)
The colon seems a part of the error message and not of the parameter / path.
change it to t.Fatalf("Chtimes '%s': %s", name, err) ???

@gj52 - From the comment above, it seems like it is WAI. So there is no solution here, because there is no bug. The t.Fatalf line is in a test and will not appear when you use the os package. What you want to be changed is essentially the String method of PathError

func (e *PathError) Error() string { return e.Op + " " + e.Path + ": " + e.Err.Error() }

You are certainly welcome to improve the error message, but this issue is specifically about Chtimes failing on FAT32.

@agnivade Hi, I would change the parameter sequence, first the error and than the wrong parameters
Don't know if GOLANG has guidelines for error messages ;-)

We're not going to change the format of this error. It has been stable for years, and is consistent with other errors.

Also, please, let's stay on topic. This issue is about Chtimes failing, not the styling of the error.

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

Wanted to comment and mention that this issue also appears to affect exFAT. The following is encountered during a docker build when Docker's storage resides on an exFAT formatted partition on Windows:

ERROR: chtimes \\?\D:\ProgramData\Docker\tmp\docker-builder907137105\.git: The parameter is incorrect.

I can also replicate this error for exfat.
I encountered this when Hugo tried to build from an exfat source
Error: Error copying static files: chtimes : The parameter is incorrect.

I encountered the same chtimes error in not finding path to /public when the source was on exFat. Switched source to a NTFS partition and the problem was gone. I was using Rstudio and blogdown.