cc @ianlancetaylor

As far as I know this is working as intended. Seeking in a directory can be meaningful. In particular you can call Seek(1, 0) to get the current offset, and then later you can seek back to that location. The test of dirinfo in (*File).Seek is to handle the case of WIndows, in which the seek method does not clear the dirinfo field.

Is there a particular reason that Seek should fail on directories on Unix systems?

Here’s a corrected test program, I missed the Readdirnames call:

https://play.golang.org/p/INPumuqPZ-V

Seek-ing in directories on Unix used to fail:

$ go1.14.15 run dir-seek.go
Seek failed for directory as expected: seek /home/tom: is a directory
$ go1.16.2 run dir-seek.go
Seek succeeded unexpectedly for directory with pos=9223372036854775807

I’ve got no objections to keeping the current behaviour, but I can see nothing in the changes that cleared dirinfo that indicated it was intentionally allowing this. I’m pretty sure it was just an accident that this started working, despite a previous explicit check, hence I figured it was the wrong behaviour.

Also while Seek can be meaningful at a system call level, I don’t see how it can be meaningful at a Go level. The dir_unix.go code buffers a full 8KiB of directory information on each read. If you tried to use Seek to remember a position, you’d always end up at the end of one of those 8KiB blocks, if I’m not mistaken, not immediately after the directory entry you’d just read as you’d expect.

Fair enough. I hadn't realized that this failed in earlier releases.

Looks like this changed in https://golang.org/cl/219143. See #35767 and #37161. The tests cases for those issues involve seeking to position 0, which has always been permitted. But, as you said, that CL changed the code so that the check to return EISDIR when seeking to a non-0 offset no longer fails.

Interestingly, returning EISDIR when seeking to a non-0 offset dates back to when the Seek method was first introduced, in d94c5ab.

I'm not quite sure what behavior we should enforce going forward. CC @randall77

I think we want Seek on directories to work for (0, io.SeekStart), (n, io.SeekStart) for n returned from a previous call to (0, io.SeekCur), and (0, io.SeekCur). So whence == io.SeekStart || (whence == io.SeekCur && off == 0). Can we return an immediate error for Seek for other cases? That might be the behavior for <=1.13 anyway.

Practically speaking, we can change the order of the tests in (*FIle).Seek to put the dirinfo test before the call to (*File).seek.

Quoting myself from CL 209961:

p.s. I hate the Readdirnames API.

Historically we've only permitted the case where the result of the Seek winds up being 0. That is, historically we have not accepted (n, io.SeekStart) for a value returned by a previous call to (0, io.SeekCur). (Despite what I said above). I think it would be OK to go back to that. Which means I think it would be OK to only accept (0, io.SeekStart), since while there are other ways to get to 0 they are needlessly complicated.