Bug 678883 - File mode bits not preserved after deployment
File mode bits not preserved after deployment
Status: CLOSED CANTFIX
Product: RHQ Project
Classification: Other
Component: Provisioning (Show other bugs)
3.0.0
Unspecified Unspecified
high Severity unspecified (vote)
: ---
: ---
Assigned To: Robert Buck
Mike Foley
:
Depends On:
Blocks: jon30-sprint8
  Show dependency treegraph
 
Reported: 2011-02-20 10:47 EST by John Sanda
Modified: 2011-11-01 17:27 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-01 17:27:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
The recipe I was using when I encountered the bug. (953 bytes, text/xml)
2011-02-20 13:51 EST, John Sanda
no flags Details
test bundle that reproduces the issue (815 bytes, application/zip)
2011-02-20 14:49 EST, John Sanda
no flags Details

  None (edit)
Description John Sanda 2011-02-20 10:47:42 EST
Description of problem:
I created a bundle recipe to deploy and start a JBoss EAP server. Starting the server failed. I discovered that the failure was due to run.sh not being executable. Prior to deployment however, run.sh along with the other scripts in the bin directory do have their executable bits set. Some how the file mode bits are getting lost during the deployment process.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 John Sanda 2011-02-20 13:50:19 EST
I tried uploading the bundle I have been using for testing, but it exceeded the max size for attachments. I will attach the recipe file I was using and then later try to upload a smaller, simpler example that reproduces the bug.
Comment 2 John Sanda 2011-02-20 13:51:01 EST
Created attachment 479786 [details]
The recipe I was using when I encountered the bug.
Comment 3 John Sanda 2011-02-20 14:49:24 EST
Created attachment 479790 [details]
test bundle that reproduces the issue
Comment 4 Robert Buck 2011-11-01 17:27:26 EDT
This is a fundamental Java limitation; Java itself does not preserve file mode bits, permissions, nothing, for any of the "supported" archive types. The only way to really support this is to natively wrap infozip or some such; that's out of scope for now unless someone else indicates otherwise.

I tested Ant, various Java API's, and various Java versions; yes, 1.6 and later have the ability to set executable bits on File objects now, but the ZipEntry and JarEntry classes expose no fields to get at the information; in effect, this is a first class data corruption issue on Sun's part.

So the workaround is to use what jsanda suggested:

    <property name="eap.dir" value="${rhq.deploy.dir}/jboss-eap-5.0"/>
    <chmod file="${eap.dir}/jboss-as/bin/run.sh" perm="+x"/>
    <exec dir="${eap.dir}/jboss-as/bin"
          executable="run.sh"
          spawn="true"
          resolveexecutable="true">
      <arg line="-b 0.0.0.0"/>
    </exec>

Note You need to log in before you can comment on or make changes to this bug.