path/filepath: fix HasPrefix

[dsnet]

The filepath.HasPrefix function has been in a deprecated-like status for the past 4 years (since 2012). The reasons why it was deprecated is described in CL/5712045. The issue with respecting path boundaries is probably the most significant.

Given that it's had a note steering people away for 4 years, there should be nearly no users of the function. Inside Google, there are 3 uses of it and all of them would have wanted the correct implementation. We should actually fix this function and bring it out of deprecated status.

The challenge with properly implementing it is getting the case-sensitivity correct. This is a dependent on the underlying filesystem and not the GOOS.

[bradfitz]

I was going to complain that the path/filepath package is purely string processing, but I forgot about Glob, which does use the os package and read from the filesystem. So fixing this properly sounds doable.

[minux]

Does package os exports portable way to query if the underlying file system is case sensitive or not? (without creating a file and test?) And what about symbolic links? If we want to fix it, we should first work out its intended behavior, which I think it's far from trivial. And I expect neither is the implementation (there could be more than one mount points along the path, and each could have different case sensitivity rules), and not every program would actually need such sophistications. (One prime example is that we don't have os.CopyFile, even thought it's such a nice thing to have.) One other reason to not fix HasPrefix is because if we did fix this, program will begin to use it, and rely on the newly documented invariants, which are not necessarily true under older Go version. But people building the program with older Go versions won't notice any build breakage, and thus will be silently using the bad implementation. I think this will cause more problem that it solves for the developer. (That is, I believe, once something is declared deprecated, it should never be taken out of that status again, or change behavior, for that matter.) If we want to fix this issue, I suggest that we add a new function in Go 1.9.

[cespare]

I agree with @minux, but for the record we did un-deprecate a function before when we fixed up debug.Stack for Go 1.6. See 2d697b2 and #12363.

[minux]

I think the runtime/debug#Stack case is different from path/filepath.HasPrefix, 1. the original implementation is not broken, both versions show the essential information, just in different formats, and the new version shows more. 2. it's meant to use for debugging, so stability is not that important. for the record, here is the difference I'm talking about: // t.go package main import ( "fmt" "runtime/debug" ) func f(i int) { if i == 0 { fmt.Printf("%s\n", debug.Stack()) } else { f(i - 1) } } func main() { f(5) } $ go1 run t.go /tmp/t.go:10 (0x400c29) f: fmt.Printf("%s\n", debug.Stack()) /tmp/t.go:12 (0x400cc8) f: f(i - 1) /tmp/t.go:12 (0x400cc8) f: f(i - 1) /tmp/t.go:12 (0x400cc8) f: f(i - 1) /tmp/t.go:12 (0x400cc8) f: f(i - 1) /tmp/t.go:12 (0x400cc8) f: f(i - 1) /tmp/t.go:17 (0x400ced) main: f(5) ..../go1/src/pkg/runtime/proc.c:244 (0x40cd87) main: main·main(); ..../go1/src/pkg/runtime/proc.c:271 (0x40ce2a) goexit: runtime·goexit(void) $ go163 run t.go goroutine 1 [running]: runtime/debug.Stack(0x0, 0x0, 0x0) ..../go163/src/runtime/debug/stack.go:24 +0x80 main.f(0x0) /tmp/t.go:10 +0x36 main.f(0x1) /tmp/t.go:12 +0x140 main.f(0x2) /tmp/t.go:12 +0x140 main.f(0x3) /tmp/t.go:12 +0x140 main.f(0x4) /tmp/t.go:12 +0x140 main.f(0x5) /tmp/t.go:12 +0x140 main.main() /tmp/t.go:17 +0x20 Accidentally switching to the old version won't cause much trouble. Unlike switching from a filesystem-aware path/filepath.HasPrefix to the old strings.HasPrefix based implementation.

[alexbrainman]

Whatever we decide to do here, I think filepath.HasPrefix is useful function. We can all complain that it is hard to implement it, but then people will write they own. We have written cmd/go.hasFilePathPrefix ourselves. Why didn't we use filepath.HasPrefix in cmd/go instead?

Alex

[RobbieMcKinstry]

Repost from a closed bug: (Sorry for the noise, I'm a newbie still!)

Just checking: this function is deprecated, and there is no alternative? Maybe a regex.Match? I assume that's why there's interest in fixing.

[zacps]

It's more complicated than regex, which is why it hasn't been solved yet.
golang/dep has a solution to this here but it might not be an acceptable replacedment for the stdlib because it does involve a stat call.

[hirochachacha]

I think checking GOOS is good enough.
It seems that the same decision was done for filepath.Rel.
Or should we deprecate filepath.Rel also?

[zacps]

Looks like Rel isn't ideal either because it doesn't take into account case insensitive filesystems. It matters less in that case as the user can simply supply the same case in both arguments.

IMO Rel should be kept how it is and we should think about adopting the solution from golang/dep for HasPrefix.