RFR 8138579: Custom launcher fails to start because of permission problem

[ecki at zusammenkunft.net]

Hm, how can a normal user "give away" the ownership of a file? Only when the test is run as root the owner can be different, but in that case root would be able to set the x bit anyway. So i am not sure the explanation is correct? (Cant read the bug)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

-----Original Message-----
From: "serguei.spitsyn at oracle.com" <serguei.spitsyn at oracle.com>
To: Jaroslav Bachorik <jaroslav.bachorik at oracle.com>, "serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net" <serviceability-dev at openjdk.java.net>
Sent: Mi., 07 Okt. 2015 20:29
Subject: Re: RFR 8138579: Custom launcher fails to start because of permission problem

Looks good.

Thanks,
Serguei

On 10/7/15 05:15, Jaroslav Bachorik wrote:
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8138579
> Webrev: http://cr.openjdk.java.net/~jbachorik/8138579/webrev.00
>
> This test is exercising a custom launcher (executable). Since it is 
> not possible to check in a file and prevent its executable flag the 
> test sets the executable flag on the fly after it has copied over the 
> platform specific launcher to a well known location.
>
> However, setting the executable flag has started to fail on Solaris 
> machines recently. I tracked down the failure to the fact that the 
> launcher is being copied with the preserved attributes - including the 
> owner and group. The original launcher owner and group differ from the 
> user the test is run under and therefore the attempt to set the 
> executable flag fails.
>
> The proposed fix is not to preserve the file attributes - the launcher 
> will be owned by the current user and the attempt to set the 
> executable flag will succeed.
>
> The patch has been tested on all supported platforms successfully.
>
> Thanks,
>
> -JB-