Re: [PATCH 0/1] MR11284: kernel32/tests: Test filename case preservation when opening existing file.

[Paul Gofman (＠gofman)]

Commit af35741d3681f21222a85900b54d95ee422fe074 regressed Dishonored - Definitive Edition which now not saving settings. It actually saves those as SETTINGS.sav file, but then when it opens it as "SETTINGS.SAV" and then GetGetFinalPathNameByHandleW() returns "SETTINGS.SAV" and not "SETTINGS.sav" it is unhappy and writes initial settings over.

There are different aspects how this change regresses the filename read back. I started fixing that locally and fixed some aspects of that, but then realized that I am not sure which overall direction will be preferred.

One side aspect is that now renaming file (e. g., with MoveFileW, as also covered by this test) does not change open file NT name (as it is different handle). This is possible to address by traversing all the files from the same inode in the server and changing NT name in each. Then, fixing up different case in lookup_unix_name(), when it takes part by part path, is also straigtforwatd, the name read from directory can easily fixup NT name (replacing attr->ObjectName with nt_name same way as it is done for reparse point translation and trailing slash removal). But then on case-insensitive FS this path is not taken and shortcut file open path in lookup_unix_name() succeeds while NT name may differ in case (the same may happen in find_file_in_dir). My test case, been locally fixed for case-sensitive Linux FS expectedly fails again in the Wine prefix created in case-insensitive fs ("mkfs.ext4 -O casefold -E encoding=utf8 /dev/..."). Now it looks like the only way is getting Unix file na
 me for the found file similar to how that was done back then in server's fd.c:set_unix_name_of_fd() (now that is removed), which reads /proc/self/fd/ on Linux to get the path or uses fcntl( F_GETPATH ) elsewhere. On top of that (this is currently not covered by this test but I tested separately), creating file with "c:\\<path>" still results in uppercase "C" on Windows (while not in Wine currently, drive part also inherits requested path). Doing these parts (especially the last one) seems like largely re-introducing removed unix_to_nt_file_name() logic.

So I am not sure, maybe instead of trying to fix all these various parts it is better to essentially revert offending commit in some way, re-implementing file name queries from server unix file name instead of relying on user provided NT file name anyhow? Also, while this is probably not directly related here, IIRC NtQueryObject() does not return file names at all on Windows, that is not mapped as kernel objects and is something for NtQueryInformationFile(), so maybe unifying file name query in wineserver this way is not too much useful going forward?

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/11284#note_144509