Did I use it incorrectly or does uv_fs_open with O_TRUNC have a bug?

[freejack811]

The uv_fs_open(libuv1.47.0) always return parameter error when I use uv_fs_open to open an existing file and want to truncate it to 0 bytes on the Windows platform (Windows 10 19045.3930), as shown in the following code:

    uv_fs_t req;
    int error = uv_fs_open(nullptr, &req, "d:/test.txt", O_WRONLY | O_TRUNC, S_IWRITE, nullptr);
    // uv_fs_open(nullptr, &req, "d:/test.txt", O_WRONLY, S_IWRITE, nullptr);  // Works fine but doesn't truncate

the error is always UV_EINVAL(-4071). Did I use it incorrectly or does uv_fs_open with O_TRUNC have a bug?

[bnoordhuis]

Does UV_FS_O_WRONLY | UV_FS_O_TRUNC work? That's equivalent to CreateFile(GENERIC_WRITE, TRUNCATE_EXISTING) and ought to work.

[freejack811]

The problem also exists when I use UV_FS_O_WRONLY | UV_FS_O_TRUNC.

[freejack811]

I'm sure this is a bug. Please see my comment below.

[freejack811]

I did some research on this issue. First I looked at the source code of libuv and found that uv_fs_open actually calls the CreateFileW function on the Window platform. The libuv function fs__open will set the local variable disposition to TRUNCATE_EXISTING and use it as the dwCreationDisposition (5th) parameter of the CreateFileW function when the flags (4th) parameter of uv_fs_open specifies O_WRONLY | O_TRUNC. Then I took a look at the WinAPI manual, and the description of TRUNCATE_EXISTING pointed out:

Opens a file and truncates it so that its size is zero bytes, only if it exists.
If the specified file does not exist, the function fails and the last-error code is set to ERROR_FILE_NOT_FOUND (2).

The calling process must open the file with the GENERIC_WRITE bit set as part of the dwDesiredAccess parameter.

So I tried adding a few lines of code here, as follows:

case UV_FS_O_TRUNC:
case UV_FS_O_TRUNC | UV_FS_O_EXCL:
  disposition = TRUNCATE_EXISTING;
  // added by me begin
  if ((access & FILE_GENERIC_WRITE) == FILE_GENERIC_WRITE)
      access |= GENERIC_WRITE;
  // added by me end
  break;

Eventually it worked, the existing file was opened and the file was truncated to 0 bytes. But I'm not sure whether this modification will affect other working modes.

[freejack811]

The fs__open function has used FILE_GENERIC_WRITE. I took a look and FILE_GENERIC_WRITE and GENERIC_WRITE are two completely different macros. This CreateFileW function is really complicated. Until now, I haven't figured out why there are two macros and their differences.

[vtjnash]

GENERIC_WRITE is a bitmask flag that is defined to mean the same as specifying STANDARD_RIGHTS_WRITE, FILE_WRITE_DATA, FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, FILE_APPEND_DATA, and SYNCHRONIZE (though not the same bits, the same meaning): https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntcreatefile

https://learn.microsoft.com/en-us/windows/win32/secauthz/generic-access-rights

[bnoordhuis]

It's the other way around, according to mingw-w64's winnt.h:

/usr/x86_64-w64-mingw32/include/winnt.h:5162:#define FILE_GENERIC_WRITE (STANDARD_RIGHTS_WRITE | FILE_WRITE_DATA | FILE_WRITE_ATTRIBUTES | FILE_WRITE_EA | FILE_APPEND_DATA | SYNCHRONIZE)

Whereas GENERIC_WRITE is just:

/usr/x86_64-w64-mingw32/include/winnt.h:2905:#define GENERIC_WRITE (__MSABI_LONG(0x40000000))

The flags don't overlap, FILE_GENERIC_WRITE == 0x120116.

[vtjnash]

No, the bits do not overlap, but the meaning overlaps. In particular, the kernel IO driver interprets the bits GENERIC_WRITE to mean to bitwise OR the rest of the given mask with FILE_GENERIC_WRITE (assuming that it is a file and not a directory or other special object). The result is that this operation (with GENERIC_WRITE) requires the user have more permissions than with FILE_WRITE_DATA alone, since the user must also have permission to change the ATTRIBUTES and EA streams on the file

[vtjnash]

Also note that STANDARD_RIGHTS_WRITE is defined to be same (bitwise) as READ_CONTROL

[freejack811]

I guessed that CreateFileW would check parameters before transferring to the kernel, so I directly used MSVC's disassembly debugging function to debug. The result is that CreateFileW calls the CreateFileInternal function, and in front of the function when dwCreationDisposition is TRUNCATE_EXISTING (5), the bt instruction is used to perform a bit test on the dwDesiredAccess parameter. It requires that bit 30(1EH, based on 0) of dwDesiredAccess must be 1, and it happens to be the bit set by GENERIC_WRITE (0x40000000). If it is not set, a parameter error will be returned. The backtrace is as shown below:

The 0x40000000 must be set to dwDesiredAccess on my operating system, this should be a mandatory requirement.
So maybe we can change the code here to:

  case UV_FS_O_WRONLY:
    access = FILE_GENERIC_WRITE | GENERIC_WRITE;
    break;
  case UV_FS_O_RDWR:
    access = FILE_GENERIC_READ | FILE_GENERIC_WRITE | GENERIC_WRITE;