Re: [PATCH v5] kernel32: Correct ReplaceFileW behaviour

[Dmitry Timoshkov]

Brock York  wrote:
>  attr.ObjectName = &nt_replaced_name;
> - status = NtOpenFile(&hReplaced, GENERIC_READ|GENERIC_WRITE|DELETE|SYNCHRONIZE,
> - status = NtOpenFile(&hReplaced, GENERIC_READ|DELETE|SYNCHRONIZE,
>                     &attr, &io,
>                     FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,
>                     FILE_SYNCHRONOUS_IO_NONALERT|FILE_NON_DIRECTORY_FILE);
>
> @@ -1788,6 +1789,19 @@ BOOL WINAPI ReplaceFileW(LPCWSTR lpReplacedFileName, LPCWSTR lpReplacementFileNa
>          goto fail;
>      }
> - /* Replacement should fail if replaced is READ_ONLY */
> - if (!GetFileInformationByHandle(hReplaced, &file_info))
> - {
> -
>    error = GetLastError();
> -
>    goto fail;
> - }
> -
> - if (file_info.dwFileAttributes & FILE_ATTRIBUTE_READONLY)
> - {
> -
>    error = ERROR_ACCESS_DENIED;
> -
>    goto fail;
> - }

There is an existing test for NtCreateFile that it's supposed to fail if
the file has read-only attribute. Probably NtOpenFile with WRITE|DELETE
access supposed to behave in a similar way. Adding such workarounds to
high level API like ReplaceFile only clutters the code with not appropriate
hacks.