Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

> 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>
>

> 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>
>>
>
>
> ------------------------------------------------------------------------------
> If you reply to this email, your message will be added to the discussion below:
> http://forum.jogamp.org/Jogamp-fat-jar-not-deploying-on-a-Windows-7-64bits-machine-tp4039604p4039643.html

> 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>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> If you reply to this email, your message will be added to the discussion below:
>>
> http://forum.jogamp.org/Jogamp-fat-jar-not-deploying-on-a-Windows-7-64bits-machine-tp4039604p4039643.html
>
>
> ------------------------------------------------------------------------------
> If you reply to this email, your message will be added to the discussion below:
> http://forum.jogamp.org/Jogamp-fat-jar-not-deploying-on-a-Windows-7-64bits-machine-tp4039604p4039644.html
>
> To start a new topic under jogl, email [hidden email]
> To unsubscribe from jogl, click here
> <
> NAML
> <http://forum.jogamp.org/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

> 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>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------