/cc @alexbrainman

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

Alex

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

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

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?
}

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

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

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

@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.

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!)

What I worried about is a consistency

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

Alex

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