Skip to content
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: File.Fd returns search handle, not directory handle, on Windows #13738

Closed
hirochachacha opened this issue Dec 27, 2015 · 12 comments
Closed

os: File.Fd returns search handle, not directory handle, on Windows #13738

hirochachacha opened this issue Dec 27, 2015 · 12 comments

Comments

@hirochachacha
Copy link
Contributor

@hirochachacha hirochachacha commented Dec 27, 2015

Currently, Fd() return search handle if the file is a directory.
But, search handle and directory handle are not the same.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa364418(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365258(v=vs.85).aspx

It's OK now, because (*os.File).Chdir, syscall.Fchdir, syscall.Fchmod are just stub.
Once someone implements syscall.Fchdir, the problem is unveiled.

https://gist.github.com/hirochachacha/bba426b5defff3d8f5fe

I think Fd() should return uintptr(syscall.InvalidHandle), if failed to obtain directory handle.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 27, 2015

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Dec 28, 2015

Yes, we should try and implement windows (*os.File).Chdir, and see what happens. Not for go1.6.

Alex

@hirochachacha
Copy link
Contributor Author

@hirochachacha hirochachacha commented Dec 28, 2015

I know.

What I want to clarify here is:
This is a bug, is not in the specifications.

Otherwise, there are no easy way to handle this. (because of the compatibility)

Thank you.

hiro

@rsc rsc changed the title os: inconsistent semantics of func (f *os.File).Fd() uintptr on windows. os: File.Fd returns search handle, not directory handle, on Windows Dec 28, 2015
@rsc rsc added this to the Unplanned milestone Dec 28, 2015
@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Dec 29, 2015

This is a bug, is not in the specifications.

Please, explain what you mean here. Are you saying that File.Fd is not documented well? If so, what should File.Fd documentation say? Thank you.

Alex

@hirochachacha
Copy link
Contributor Author

@hirochachacha hirochachacha commented Dec 29, 2015

I think File.Fd returns wrong value, from beginning. (maybe 1.0?)
If we admit it's in the specifications, then we have no chance to treat directory handle on 1.x.
Because, AFAIK, there are no easy way to distinct search handle and directory handle in user side.

package main

import (
  "os"
)

func main() {
  f, _ := os.Open(".")

  println(f.Fd()) // is this search handle or directory handle?
}
@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Dec 29, 2015

I think File.Fd returns wrong value ...

Maybe.

If we admit it's in the specifications, ...

Documentation says:

Fd returns the integer Unix file descriptor referencing the open file.

There is no such thing as "Unix file descriptor" on Windows. So I am not sure, if what you want is in the spec or not.

What exactly do you propose we do here?

Alex

@hirochachacha
Copy link
Contributor Author

@hirochachacha hirochachacha commented Dec 29, 2015

I think File.Fd should return uintptr(syscall.InvalidHandle), if the file is a directory.

Because current code always return search handle if the file is a directory.

That's what I want to propose.

Thank you.

hiro

@mikioh mikioh added the OS-Windows label Dec 29, 2015
@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Dec 29, 2015

I think File.Fd should return uintptr(syscall.InvalidHandle), if the file is a directory.

Why your proposal is better than what we currently have?

Alex

@mattn
Copy link
Member

@mattn mattn commented Dec 29, 2015

@alexbrainman @hirochachacha 's opinion make sense for me. However, we can implement (*os.File).Chdir without using Fd(). For example, take dirname field on File structure. I wonder what is use-case of Fd() for the directory on windows.

@hirochachacha
Copy link
Contributor Author

@hirochachacha hirochachacha commented Dec 29, 2015

I know.
If go team decide not to treat directory handle in os package, it's OK for me.
What I worried about is a consistency, no practical use-cases in my mind. (sorry!)

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Dec 29, 2015

What I worried about is a consistency

And why returning syscall.InvalidHandle for directories is more "consistent" than returning "search handle"?

Alex

@hirochachacha
Copy link
Contributor Author

@hirochachacha hirochachacha commented Dec 30, 2015

Actually, I'm not a windows expert, so I'm not confident.

First, analogy to unix systems, if I open a directory file, I expect fd is a "directory file descriptor".
AFAICS, closest concept of "directory file descriptor" on windows is "directory handle".

Whole my suggestions are related to the question:
What problem arise If we introduce "directory handle"?

And my answer is:
"search handle" and "directory handle" can't coexist.
So we need to invalidate "search handle", if we want to introduce "directory handle".

Secondly, syscall package seems to support my point of view.
Like or not, syscall package provide "posix emulation layer" for all supported OS.
And my view is similar to "posix emulation", I think.

Anyway, I don't need to argue any more.
If current behavior is intentional, it's OK.

Thank you Alex for clarifying my point.

hiro

@golang golang locked and limited conversation to collaborators Dec 29, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.