-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
io/fs,os: fs.ReadDir with an os.DirFS can produce invalid paths #44166
Comments
Marking as release-blocker pending triage from @rsc. |
It seems like the two options are:
In general I would err on the side of showing that there's an inaccessible file than pretending it doesn't exist at all, but I'd be happy to listen to good arguments for the other. |
Two more options:
|
I think the reason for rejecting backslashes in the first place is so that But we can always reject backslashes on Windows in the FS-specific So that leaves |
The reason to reject backslashes is not quite to cater to Windows users but instead to define a simpler subset of possible names for all implementations to handle. Backslashes are a perennial special case in portable file system implementations, because of Windows, and it simplifies all future implementations to remove them from the required interface entirely. It seems clear that approximately no one actually uses files named |
Also, in my experience, if you do have a file named If we accept backslash in ValidPath and in os.DirFS and also at some later point allow Create, then those bugs will continue to be created. If we keep the no-backslashes rule, then we prevent them. |
Hmm. But if, say, someone implements a file browser on top of If we disallow the path, then being able to successfully traverse that path would require a custom |
(To be clear: I agree that paths involving backslashes are usually symptoms of other bugs. I just think they almost always occur on the |
Thinking about this issue in relation to #44092: we're returning an empty list from If we want to raise the bar on diagnosing “things that are probably bugs”, why raise it for |
If There's very often strange workarounds and translation layers. I've been told in the past that Windows syscalls use forward slashes, and that the translation to backslashes happens closer to the user interface. I know MacOS's internal representation used to use What should It seems to me that probably the right answer is for Given a plain file |
Investigating this issue I found the issue #44171 that might be interesting for this discussion. |
@seebs You are making the "any model must provide the union of all the features of the possible underlying systems being modeled" argument. But we have avoided that for package os - instead, we provide a simplified model that does not capture everything about all operating systems. The io/fs package aims to do the same. |
Hmm. Well, the model can just be target-specific, in which case, valid paths would vary between systems, but that seems like it would be bad. In which case, there's either at least one path which is acceptable to the model but can't be used on a particular target, or at least one path which is unacceptable to the model but can be used on a particular target. Or both, I guess. I think part of the issue is that the other tools, like Create or Open, can still manipulate these paths, which creates two conflicting and incompatible ways to think about file names. So at least some names valid to Open will be rejected as InvalidFile by io/fs. And at least some names which io/fs considers valid will probably be invalid for Open. That seems bad too... |
While I am very sympathetic to the argument of not wanting to model every possible file system behavior and then having to maintain the complexity forever, if someone were to build antivirus software in Go and relied on the standard library for file system access as stdlib is a certain 'guarantee' of quality, presumably it wouldn't be ideal if all it took for malware to hide from a scan is to have a backslash in its name. Certainly not if the headline would be along the lines of 'due to a bug in the Go standard library'. |
Change https://golang.org/cl/290709 mentions this issue: |
As of now, Go actually can't reliably do Create/Open with Windows filenames that contain invalid UTF-8 sequences (e.g. two UTF-16 surrogates side by side). |
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Ran the test in https://play.golang.org/p/HY3-ANaECG-.
What did you expect to see?
All paths returned by
fs.ReadDir
(and, by extension,fs.WalkDIr
) satisfyfs.ValidPath
.What did you see instead?
The text was updated successfully, but these errors were encountered: