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

Bắt đầu bằng cách truy vết các đường dẫn tạo của fs.writeFile(), fs.promises.writeFile() và fs.promises.open(), sau đó so sánh cách chúng xử lý mode với fs.chmod() và filehandle.chmod(). Tái hiện vấn đề trên Linux với mode 0o777 và xác minh rằng các tệp mới được tạo vẫn giữ bit ghi công khai được cung cấp mà không thay đổi hành vi đối với các tệp hiện có.