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 を使って問題を再現し、新しく作成されたファイルが指定されたパブリック書き込みビットを保持し、既存のファイルの動作が変わらないことを確認します。