On Sat, Aug 28, 2021 at 6:14 AM Alexandre Julliard julliard@winehq.org wrote:
"Erich E. Hoover" erich.e.hoover@gmail.com writes:
I would love any and all feedback on updated versions of my "Reparse Point" patches, which are now available in staging: https://github.com/wine-staging/wine-staging/tree/master/patches/ntdll-Junct...
My general impression is that both the design and the implementation are trying to be too clever for their own good.
Well, that's obviously not what I was hoping to hear. I proposed an alternative approach a couple years ago ( https://www.winehq.org/pipermail/wine-devel/2019-March/142536.html ) that stored the reparse tag in the symlink's access time, which is obviously a lot simpler than encoding the tag in the filename, but that approach has some downsides and Jacek suggested this approach as a way to work around them.
I would first question the assumption that these have to be actual, resolvable symlinks. What if they weren't?
Funny you ask, at one point I actually put together an attempt at this and it became pretty messy very quickly. It's not difficult for symlinks that are files, but directory symlinks mean that we essentially need to replace path resolution at every single place where we want to work with a unix path. For example, let's say that we have a symlink at C:\test that points to C:\windows. An attempt to access C:\test\system32 would nominally be converted to ${WINEPREFIX}/drive_c/test/system32 and we would pass this path down to the OS. If we have a "custom" symlink implementation then we need to parse the path and resolve each element in order to get the real path to the file on the system, whereas the OS takes care of this for us if we use "proper" symlinks. Where this gets really nasty when you start trying to deal with the parent directory (".."). Parent directory handling actually has different meaning depending on the context, most of the time it means wrt. the target (which makes resolving each element important) but in the context of commands that operate on the working directory you need to work with the "original" path. This is all _possible_ to take care of, but at that point we're implementing so much custom path handling that you're talking about a substantial undertaking (that needs to be called everywhere there's a unix path that we pass down to the OS). But maybe there's a solution you're seeing here that I'm not?
Best, Erich