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.spit...@oracle.com" <serguei.spit...@oracle.com> To: Jaroslav Bachorik <jaroslav.bacho...@oracle.com>, "serviceability-dev@openjdk.java.net serviceability-dev@openjdk.java.net" <serviceability-dev@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-
