RFR: 8343020: SecureDirectoryStream not supported on MacOS

[David M. Lloyd]

On Thu, 24 Oct 2024 21:54:55 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
> 
> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
> 
> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.

The debug output is not revealing much (the boot module finder just returns `null` for `java.base`), and it seems to be failing too early to attach a debugger, so I'm on to `println` debugging now.

Another logical discrepancy is that `futimes` does in fact seem to work in my standalone `test.c` testing. And anyway, why does boot depend on `futimes`? So I think the problem may be unrelated to `futimes` per se, but rather is due to another capability that is used by `SecureDirectoryStream` that is indirectly enabled. So I'm focusing my high tech debugging strategy in that area as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2437667577