-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
os: TestMkdirAll failing Plan 9 #23918
Comments
Before the change:
After the change:
This issues emphases a specific behavior on Plan 9. It can be reproduced this way:
Mkdir("file") will return an error, while Mkdir("file/") won't. |
Sorry, it seems I've missed your issue. I'm not sure how to fix this issue properly on Plan 9 yet. Should we change the behavior of the fstat syscall in the Plan 9 kernel? Should we remove trailing slashes in the implementation of os.Stat or dirstat on Plan 9? I think the safest change for now would be to add an exception for Plan 9 in the implementation of os.MkdirAll, so we get the same behavior as before. I'll propose a CL. |
No worries. Sorry for breaking plan9 build.
I was going to suggest the same,
Thank you. Feel free to put me as a reviewer. I will push +2 button if I am not in bed. Alex |
MkdirAll is now being called with a trailing slash on the path. In the case where the path exists and is a file, the "fast path" code will now be bypassed -- on all platforms, not just Plan 9 -- because the Stat in line 22 returns error "not a directory", and therefore the dir.IsDir call will never be executed. The Plan 9 misbehaviour is actually independent of the trailing slash -- the underlying system call
doesn't return an error if path exists and is a file, whether or not it ends in a slash. In the altered MkdirAll, it might be a good idea to check the error from the first Stat with IsNotexist, to reinstate the fast path in the case of a file. But I think we should workaround the underlying Plan 9 problem by having syscall.Mkdir check for pre-existing path, and not relying on the system call to do it right. |
Change https://golang.org/cl/95055 mentions this issue: |
@millerresearch Yes, you're right. Could you submit a CL? |
We could also just revert CL 86295 and I will try to find different fix for CL CL 86295. Alex |
@0intro, I think the change should be Independent of this correction, I think I have a workaround for the silly Plan 9 behaviour of syscall.Mkdir, so I'll submit a CL for that. |
Change https://golang.org/cl/94777 mentions this issue: |
Change https://golang.org/cl/95095 mentions this issue: |
Change https://golang.org/cl/95255 mentions this issue: |
…g slash CL 86295 changed MkdirAll to always pass a trailing path separator to support extended-length paths on Windows. However, when Stat is called on an existing file followed by trailing slash, it will return a "not a directory" error, skipping the fast path at the beginning of MkdirAll. This change fixes MkdirAll to only pass the trailing path separator where required on Windows, by using an OS-specific function fixRootDirectory. Updates #23918 Change-Id: I23f84a20e65ccce556efa743d026d352b4812c34 Reviewed-on: https://go-review.googlesource.com/95255 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David du Colombier <0intro@gmail.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Since CL 86295, TestMkdirAll is failing on Plan 9.
See https://build.golang.org/log/b073356bfd34ac9b38f472e8ba905e166cd383c6
The text was updated successfully, but these errors were encountered: