RFR: 8165643: SecureDirectoryStream doesn't work on linux non-x86

Alan Bateman Alan.Bateman at oracle.com
Thu Sep 8 18:45:01 UTC 2016

On 08/09/2016 17:10, Martin Buchholz wrote:

> On Thu, Sep 8, 2016 at 1:06 AM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>     On 07/09/2016 22:52, Martin Buchholz wrote:
>         Hi Alan and Chris,
>         Here's a bad fix for
>         https://bugs.openjdk.java.net/browse/JDK-8165643
>         <https://bugs.openjdk.java.net/browse/JDK-8165643>
>         http://cr.openjdk.java.net/~martin/webrevs/openjdk9/SecureDirectoryStream-non-x86/
>         <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/SecureDirectoryStream-non-x86/>
>         <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/SecureDirectoryStream-non-x86/
>         <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/SecureDirectoryStream-non-x86/>>
>     I wonder if we can remove fstatat64_wrapper completely, the reason
>     this code has this is because the support for this function was
>     patchy at the time (some of the platform/versions that the JDK was
>     supported on didn't have it). If you don't want to go that far
>     then that is okay, I just wonder if you could at least avoid have
>     one for i386 and one for 64-bit.
> It's straightforward to extend my patch to the __i386 case.  It's 
> somewhat less straightforward to add configure tests for all the *at 
> functions here.  But I only have access to 64-bit Linux at the moment, 
> so I can't do proper testing.  It makes sense for someone at Oracle to 
> make more extensive changes.  Feel free to do a friendly takeover of 
> this change.  The total amount of work will end up smallest 
> if JDK-8165620 actually gets tackled.
Yeah, the matrix of "supported" build/run platforms makes it harder. 
Your patch is fine for now.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20160908/3808bbcb/attachment.html>

More information about the nio-dev mailing list