Add fs.ResolvePath to resolve symbolic links - #275
Conversation
`filepath.EvalSymlinks` does not work well on Windows, and can enter infinite loops in certain situations and error out. Use Win32 API GetFinalPathNameByHandle to handle path resolution. Implementation based off on: containerd/containerd#5411 Signed-off-by: Hamza El-Saawy <hamzaelsaawy@microsoft.com>
7616c29 to
79c75a6
Compare
|
Can we carry over the tests from https://github.com/containerd/containerd/blob/main/pkg/os/os_windows_test.go? |
I wanted to avoid that since that would |
Kevin Parsons (@kevpar) |
| // Specific Object Access | ||
| // from ntioapi.h | ||
|
|
||
| FILE_READ_DATA AccessMask = (0x0001) // file & pipe |
There was a problem hiding this comment.
Same with constants, if it's in golang.org/x/sys/windows, let's use those instead.
There was a problem hiding this comment.
As in, create values that just reference windows.* for their definition?
There was a problem hiding this comment.
Do we need to define a FILE_READ_DATA const at all? I would think we can just use the const from the other package.
There was a problem hiding this comment.
the sys/windows constants are not typed, so we lose the ability to type-check and catch bugs that way
and the general constants were all copied in from the corresponding headers, since it was the same amount of work to copy in the ones we needed vs all of them
There was a problem hiding this comment.
Hmm, the general philosophy has been to carry as little as we can here, and rely on golang.org/x/sys/windows for the bulk of Windows support. I'd like to not get in the habit of re-creating functionality that lives in windows as well.
Can we get away without using typed constants here? Alternately, can we just add the minimum set of typed constants here that we need? And then we could try to get windows to type theirs (though that might be tough, as it is a breaking change).
There was a problem hiding this comment.
I doubt they would, since the majority of that code seems auto-generated.
I just copied-pasted the constants here from the relevant header files, so it was trivial to add of them, but ill whittle the number down to just what we use here.
There was a problem hiding this comment.
We could do away with the types all together, but I am hesitant to do so, since the function signatures tend to be pretty crowded (eg, CreateFile(*uint16, uint32, uint32, *windows.SecurityAttributes, uint32, uint32, wiindows.Handle)) and having types prevents mixing up parameters
There was a problem hiding this comment.
In the interest of not blocking the PR I think this is okay as is. I am interested in longer term how we can push things upstream to stdlib and x/sys/windows rather than accumulating more bits specific to this repo, so that would be a good thing to think about.
Signed-off-by: Hamza El-Saawy <hamzaelsaawy@microsoft.com>
Signed-off-by: Hamza El-Saawy <hamzaelsaawy@microsoft.com>
Update logic to try querying for normalized path initially, then use opened path if access is denied. Signed-off-by: Hamza El-Saawy <hamzaelsaawy@microsoft.com>
Kevin Parsons (kevpar)
left a comment
Kevin Parsons (kevpar)
left a comment
There was a problem hiding this comment.
The resolve logic looks fine to me. It would be good to have someone else specifically look at the string buffer parts since I didn't focus on that.
3 participants
filepath.EvalSymlinksdoes not work well on Windows, and can loop indefinitely in certain situations and error out.Add
ResolvePath, which uses the Win32GetFinalPathNameByHandleto resolve the final path of a file by first opening it.Add
"internal/stringbuffer".WStringstruct to maintain a pool of[]uint16buffers for use with interacting with the Win32APIsAdd
"internal/fs"pkg with Win32CreateFile,GetFinalPathNameByHandle, and associated flags and access masksCore implementation is based off of: containerd/containerd#5411
Signed-off-by: Hamza El-Saawy hamzaelsaawy@microsoft.com