Setting the mode from a file creation method will unset the 0x10 (public write) bit

Version

25.9.0

Platform

Linux [xxxx] 5.15.0-174-generic #184-Ubuntu SMP Fri Mar 13 18:41:50 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

fs

What steps will reproduce the bug?

Confirmed in 25.8.1, 25.9.0. Passing a 'mode' argument to at least the following methods:
fs.writeFile()
fs.promises.writeFile()
fs.promises.open()

Will set the supplied mode to the file, but with the bit at 0x10 unset (file writable by others, or S_IWOTH from the file mode constants being unset.) For example, setting the mode to 0o777 in these functions (R/W/X by user/group/public) results in a file with 0o775 being applied instead.

Setting the mode by filehandle.chmod(), fs.promises.chmod(), or fs.chmod() works as expected.

Setting the mode in a separate operation runs the risk of the mode not being properly set if the operation failed.

How often does it reproduce? Is there a required condition?

This applies at file creation. If the file already exists, then (as per expected behavior) the mode is not set at all.

What is the expected behavior? Why is that the expected behavior?

The expected behavior is for the supplied mode to be the actual mode at file creation.

What do you see instead?

The file is created with the supplied mode but without the bit at 0x10 being set.

Additional information

No response

首先跟踪 fs.writeFile()、fs.promises.writeFile() 和 fs.promises.open() 的创建路径，然后将它们对 mode 的处理与 fs.chmod() 和 filehandle.chmod() 进行比较。在 Linux 上使用 mode 0o777 重现该问题，并验证新创建的文件会保留所提供的公共写入位，同时不改变现有文件的行为。