On 8/31/21 11:25 AM, Erich E. Hoover wrote:
On Tue, Aug 31, 2021 at 4:14 AM Alexandre Julliard julliard@winehq.org wrote:
"Erich E. Hoover" erich.e.hoover@gmail.com writes: ... We are already resolving the path element by element because of case insensitivity, it seems to me that reparse point resolving would fit right in there. All you need is to make sure the initial stat() shortcut fails, which you can do by creating a dangling symlink for instance. Though my feeling is that using a normal file would make things easier, say by appending some magic filename suffix.
The difficulty isn't resolving element by element, it's doing that in two different ways depending upon the context. The parent directory inside a symlink works differently depending on the context, where that's not true for files with a different case ( chdir("..") behaves the same no matter what case the directory is ). A Linux example (Windows works the same way): === ~/tmplnk$ mkdir -p test/target ~/tmplnk$ ln -s test/target link ~/tmplnk$ cd link/ ~/tmplnk/link$ ls .. target ~/tmplnk/link$ cd .. ~/tmplnk$ ls link test === The problem I ran into is that if you treat this incorrectly then it will cause subtle breakages all over the place. How I attempted to solve this was to keep the "original" path around and resolve it locally everywhere that it needs to be resolved, this approach proved to be very messy due to the large number of ways that we use unix paths. I believe that it's also possible to instead immediately resolve the path and pass the "resolved" path around, but then we would need to change the working directory handling to _not_ use the normal path processing ( otherwise you will break SetCurrentDirectory("..") ). I say "believe" because, to my knowledge, the working directory handling is the only special case that requires the "original" path. This approach might be more viable, but I didn't get around to trying it. I mostly did this for fun, but either way I didn't think you would be a fan of these approaches due to the unnecessary duplication of the OS path resolution behavior of symlinks.
Wait, but by the time we do path resolution, aren't we guaranteed to have an absolute path that's free of . or ..? I thought that RtlDosPathNameToNtPathName() got rid of all of those for us.