On 4/23/21 5:52 PM, Gabriel Ivăncescu wrote:
+/***********************************************************************
nt_to_unix_file_name_with_casing
- Same as nt_to_unix_file_name, but additionally return unix file name
- without path, with the original casing from the NT file name.
- */
+static NTSTATUS nt_to_unix_file_name_with_casing( const OBJECT_ATTRIBUTES *attr, char **name_ret,
char **casing_ret, UINT disposition )+{
- int len = attr->ObjectName->Length / sizeof(WCHAR);
- const WCHAR *nt_filename;
- NTSTATUS status;
- char *casing;
- /* NT name may not be NUL terminated; look for last \ character */
- for (nt_filename = attr->ObjectName->Buffer + len; nt_filename != attr->ObjectName->Buffer; nt_filename--)
if (nt_filename[-1] == '\\')break;- len = attr->ObjectName->Buffer + len - nt_filename;
I was about to sign it off as it looks good to me, but then I wondered what would happen if there's a trailing '\' in the name buffer. I don't think there's any guarantee the input is sane.
I quickly checked what the new tests do in such case, and on Windows the ntdll link tests seems to be happily doing something with such trailing backslash (haven't tried the other). I don't know if it treats the path as a folder or something else.
It also looks like nt_to_unix_file_name is already handling the case somehow, as it strips the trailing backslash from the unix_name (while keeping it in the nt_name buffer). I don't know if that's on purpose or not.
Maybe it could return the proper casing for the last path component too as it has more knowledge of what is been done?