> we may try this patch here ..
>
> https://jogamp.org/git/?p=gluegen.git;a=commit;h=4375d2824ac6ff656df184ea0c19ab781e3524e8
>
> "
> Bug 1219, Bug 1231: Avoid deflating test-exe on Windows using
> java.nio.file.Files.isExecutable(Path)
>
> Attempt to resolved virus scanner false positive detection on Windows
> while deflating the native code test-exe file in the temporary folder.
>
> As Julien Gouesse suggested, using Java 1.7's
> java.nio.file.Files.isExecutable(Path)
> _may_ resolve the issue, this has to be thorougly tested.
>
> This patch favors the nio's isExecutable file's ACL test
> over the more intrusive execution itself using a simple shell script file w/
> set executable flag.
>
> Mind that previous tests allowed the shell script's execution,
> even if the temp folder did not allow execution of native code.
>
> We have to see how our testing results will be on this attempt.
> "
>
> On 3/22/19 12:35 PM, Sven Gothel [via jogamp] wrote:
>
>> I glanced over the implementation of OpenJDK 8's
>> 'java.nio.file.Files.isExecutable(Path)',
>> which eventually issues java.nio.file.spi.FileSystemProvider.checkAccess(..)
>> and on 'Unix' it will test the files via:
>> "
>> NAME
>>        access, faccessat - check user's permissions for a file
>>
>> SYNOPSIS
>>        #include <unistd.h>
>>
>>        int access(const char *pathname, int mode);
>> "
>>
>> This should be sufficient for the executable test, as we do nothing else :)
>>
>> However, the problem arises that we need to bootstrap this test with a file
>> in the first place. This task of extracting and placing the file
>> in said folder potentially causes the virus scanner to freeze the process.
>>
>> On all platforms but Windows, we use a simple empty file to test.
>> We (?)may find time to test with same empty file on Windows.
>> This test requires one to set the ACL permissions to non executable,
>> on GNU/Linux you would need to mount the temp folder non-executable or also
>> use said ACLs if supported.
>>
>> Cheers, Sven
>>
>> On 3/22/19 10:57 AM, Sven Gothel [via jogamp] wrote:
>>
>>> Yes, to make sure that the user is capable to execute files on a given path
>>> one sadly to test today.
>>> (execute == native lib loading)
>>>
>>> The filesystem's executable mount option or advanced attributes differs from
>>> out old 'directory is executable' to simply enter/read the directories
> content.
>>>
>>>> Files.isExecutable(Path) (available since Java 1.8) should work.
>>>> java.nio.files.Files.getPosixFilePermissions()
>>>
>>> If the above can replace the 'intrusive' exe-test on all platforms,
>>> we simply can use it where available via reflection.
>>> If so .. great stuff.
>>>
>>> +++
>>>
>>> Here is a commit in one branch, which I will merge to master w/ the javafx
>>> branch, disabling the exe test altogether. This of course will render
>>> the whole automatic library loading void.
>>>
>>>
>>
> https://jogamp.org/git/?p=gluegen.git;a=commit;h=e7ac6b284eb3515f552cba491c43efe75f0a4eba
>>>
>>> On 3/22/19 10:39 AM, gouessej [via jogamp] wrote:
>>>
>>>> The pitfall with File.canExecute() (available since Java 1.6) is that it
> might
>>>> tell that a file is executable whereas its permissions indicate that it isn't
>>>> :s whereas Files.isExecutable(Path) (available since Java 1.8) should work.
>>>> java.nio.files.Files.getPosixFilePermissions() would work too:
>>>> https://jogamp.org/bugzilla/show_bug.cgi?id=1219#c71
>>>>
>>>> Do you want me to provide a patch?
>>>> Julien Gouesse | Personal blog <http://gouessej.wordpress.com> | Website
>>>> <http://tuer.sourceforge.net>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------