-
Notifications
You must be signed in to change notification settings - Fork 18k
path/filepath: Rel() returns invalid path if volume case is different #10802
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
We can fix drive letter comparison. But the problem is more general - windows paths are not case sensitive. So, for example, filepath.Rel( filepath.Rel is also broken when we walking from one drive to another. It has no meaning for something like filepath.Rel( Alex |
Hi, Alex! I've encountered this call in some command-line app, and I guess, a lot of filesystem-related command line apps are already using or will use this necessary call. Is it really ok to abandon this, when so simple solution is in the air?
But you can compare their both lower or uppercase versions. The only problem - before returning the result you'll have to return the substring in original case - it will might be a clunky solution, but still possible.
I think it would be trivial to compare both drive letters / isUNC before actual comparsion. So, in your specific example, it would be absolutely ok to return "Rel can't make ..." error. |
Fair enough. We can do as much as we can. @kpashka what you like to try and send this change? Alex |
It may be worth fixing this to help the go command (#11409). What is the definition of case-insensitive on Windows? Is it ASCII only, or are c:\δ and c:\Δ the same file name too? |
I really don't know. I use English Windows version. For me everything is ASCII.
This issue is easy, because drive letters are always 'a' to 'z' - there is no unicode here. You were always against treating windows paths as case-incensitive. So I stopped arguing. Maybe we should start ignoring case in drive letter and see where it gets us. I was fighting similar battle (see issue #11459) just the other day. Mind you this issue is about filepath.Rel. filepath.Rel coubld be overkill for #11409? Alex |
From filepath.Rel:
But in Windows I got an error as shown here: Andrew |
CL https://golang.org/cl/16795 mentions this issue. |
@AngangGuo I don't see your problem is the same as stated in this issue. If you think you have a problem, you should create new issue. Alex |
Thanks. I've create a new issue here: Andrew |
Oddly enough, something like
hangs on my Win7 box using tip. The problem doesn't happen with Go 1.5.1. Adding a couple of tests: diff --git a/src/path/filepath/path_test.go b/src/path/filepath/path_test.go
index 057aa6a..3a11ec4 100644
--- a/src/path/filepath/path_test.go
+++ b/src/path/filepath/path_test.go
@@ -1034,6 +1034,8 @@ var winreltests = []RelTests{
{`C:\`, `D:\`, `err`},
{`C:`, `D:`, `err`},
{`C:\Projects`, `c:\projects\src`, `src`},
+ {`C:\Projects`, `C:\projects`, `.`},
+ {`C:\Projects`, `c:\projects`, `.`},
}
func TestRel(t *testing.T) { cause |
It sure does. Filled issue #13258. Thank you. Alex |
Go version -
go1.4.2 windows/amd64
Operating system -
Windows 7 64-bit
The problem:
Output:
Expected:
I've ocassionally found this when some go program's
os.Getcwd()
call returned me a path with lowercased volume name - not sure why this happened, can't reproduce anymore. Some users, who set theirGOPATH
to something likee:\Projects
might have problems.Probably, on Windows,
VolumeName()
should have separate implementation like this:Helpful link - Naming Files, Paths, and Namespaces
The text was updated successfully, but these errors were encountered: