x/sys/unix: file type information from dirents inaccessible #14856
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
Milestone
Comments
|
Note that ParseDirent is only part of answer to parsing dirents,
you also need to use type Dirent.
It's only used to handle the variable length field Name in type
Dirent, so to parse all Dirents, you can do this:
// assume b is the byte slice containing dirents
names := make([]string, 0, 1)
dirent := (*Dirent)unsafe.Pointer(&b[0])
l, _, names := unix.ParseDirent(b, 1, names)
b = b[l:]
// now you have dirent and names[0]
The details are a little more complicated, as you need to remember
to fill in the buffer when necessary, please see (*os.File).readdirnames
for details:
https://golang.org/src/os/dir_unix.go?s=300:362#L8
|
|
If you want inspiration, at least three independent implementations for that are already out there: |
gopherbot
added
the
compiler/runtime
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
golang.org/x/sys/unix.ReadDirent reads a Dirent that includes the filename and the file type. golang.org/x/sys/unix.ParseDirent parses out the filename.
Linux and OSX include the file type in the Dirent. Go should make this information accessible. This info would let programs skip stat'ing files of the wrong type.
It would not be feasible to change ParseDirent to do so because it would require a type signature change.
If we can agree on a plan, I can (try to) make the code change.
Here's my proposal, but I've never made a change to Go so it may be off-base.
The package unix could offer a func like "ParseDirentFully" that returned a struct or interface that offered all dirent members available. ParseDirent could call ParseDirentFully to return just the name. (The naming could be better, e.g. ParseDirent and ParseNameFromDirent, but that would break existing code) The code in syscall_*.go already casts to the dirent type from the underlying FS, so it could access another member.
(I am using go 1.5.1 on darwin/amd64. I have inspected code on tip and believe this issue still applies)
The text was updated successfully, but these errors were encountered: