e.g. Bash on Windows, or 'Linux' zones in Solaris...
__NR_memfd_create is a preprocessor macro, so we can test for it's existence at compile-time and disable code which uses that syscall.
At runtime we already check for errno == ENOSYS, presumably Bash on Windows will act accordingly so the shm_open fallback can be run.
If shm_open fails, which is really just a wrapper around opening from /dev/shm, then the portable UNIX-like file_exec will be used.
Original commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9183df25fe7b194563db3fec6dc3202a5855839c
Another interesting option is O_TMPFILE, supported since Linux 3.11, whereas memfd_create is supported only in Linux 3.17, it's unlikely that either are supported by 'Bash on Windows':
Specifying O_EXCL in conjunction with O_TMPFILE prevents a
temporary file from being linked into the filesystem in the
above manner. (Note that the meaning of O_EXCL in this case
is different from the meaning of O_EXCL otherwise.)
There are two main use cases for O_TMPFILE:
* Improved tmpfile(3) functionality: race-free creation of
temporary files that (1) are automatically deleted when
closed; (2) can never be reached via any pathname; (3) are
not subject to symlink attacks; and (4) do not require the
caller to devise unique names.
* Creating a file that is initially invisible, which is then
populated with data and adjusted to have appropriate
filesystem attributes (fchown(2), fchmod(2), fsetxattr(2),
etc.) before being atomically linked into the filesystem
in a fully formed state (using linkat(2) as described
above).
O_TMPFILE requires support by the underlying filesystem; only
a subset of Linux filesystems provide that support. In the
initial implementation, support was provided in the ext2,
ext3, ext4, UDF, Minix, and shmem filesystems. Support for
other filesystems has subsequently been added as follows: XFS
(Linux 3.15); Btrfs (Linux 3.16); F2FS (Linux 3.16); and ubifs
(Linux 4.9)
e.g. Bash on Windows, or 'Linux' zones in Solaris...
__NR_memfd_createis a preprocessor macro, so we can test for it's existence at compile-time and disable code which uses that syscall.At runtime we already check for
errno == ENOSYS, presumably Bash on Windows will act accordingly so theshm_openfallback can be run.If
shm_openfails, which is really just a wrapper around opening from/dev/shm, then the portable UNIX-likefile_execwill be used.Original commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9183df25fe7b194563db3fec6dc3202a5855839c
Another interesting option is O_TMPFILE, supported since Linux 3.11, whereas memfd_create is supported only in Linux 3.17, it's unlikely that either are supported by 'Bash on Windows':