os: ReadDir and Readdir on a File opened from a relative path try the wrong paths for FileInfo structs
#62028
Comments
bcmills
added
the
NeedsInvestigation
|
In general Chdir breaks plenty of invariants, and we're not likely to try to work around that fact, simply because it's impossible to catch them all and just makes things more brittle. The only safe Chdirs are (1) at quiet moments when nothing else is going on and you're not going to try to reuse FS state from before the Chdir afterward, which typically reduces to (1a) at startup, and (2) during os/exec by setting cmd.Dir, which doesn't affect your process. If there was some compelling use case where Open(dir), Chdir, ReadDir+Info, dir.Close was common, then I think the fix would be optimistic fstatat in the implementation of Readdir and the implementation of DirEntry.Info, with the latter falling back to name-based stat if the directory fd has been closed. But I'd want to see that use case before complicating this code. A racing Chdir in another goroutine would be the most common way to get that sequence, but in that case the Chdir is racing with Open and so you have bigger problems. Leaving this open but probably we won't fix this unless there is a more compelling demonstration of this arising in actual practice. |
Note that the But I agree that this doesn't seem to arise in real-world use. (I noticed it in the context of thinking about edge-cases while reviewing https://go.dev/cl/518195.) |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes.
What did you do?
os.Opento open anos.Filefor a relative directory.os.Chdirto change the current working directory.ReadDirorReaddiron theFileopened in step (1).FileInfos.(https://go.dev/play/p/bLLMvUJGu_u?v=gotip)
What did you expect to see?
The
FileInfos should correspond to the directory entries relative to theFile.What did you see instead?
On Linux:
ReadDirproduces the directory contents relative to the current directory instead of the opened file.ReaddirproducesDirEntrycontents relative to the opened file, but calling theInfomethod on those entries attempts to open the wrong paths (compare os: File.Stat on Windows doesn't use file handle for directories #52747).It isn't clear to me how this can be fixed in general — it is possible to use
fdopendirto read the correct entries while the parent file is still open, but if the parent file is closed before theInfomethod is called on the returnedDirEntry, I don't see a standard API to reliably open the correct path.The text was updated successfully, but these errors were encountered: