The failure is due to the parent directory not existing. In this case, the parent is /home/biljana/JBoss/jboss-eap-5.1.2/jboss-eap-5.1/jboss-as/server/default/deploy/myTest. Because nothing is actually being created directly in the parent, the parent does not get created and therefore, the result is that when you attempt to use the parent directory in a relative path reference, it will fail because it doesn't exist. This same error occurs if you attempt to execute the same command from a command-line. For example:

    touch /opt/jboss/jboss-eap-5.2.0/jboss-as/server/all/deploy/myTest/../../conf/app.properties
    touch: cannot touch `/opt/jboss/jboss-eap-5.2.0/jboss-as/server/all/deploy/myTest/../../conf/app.properties': No such file or directory


One way to resolve this would be to make rhq:file create the destination path.

Changing the title of this bug to be more accurate to the issue identified. 

Relative links when defining destinationFile in the deploy.xml are broken >>> Relative paths to rhq:file element fail if parent deploy destination has not yet been created

This is because the issue only relates to relative paths that name a parent directory that does not exist. When rhq:file processes the destinationFile or destinationDir attribute it checks to see if the directory exists. However, this fails if the destination directory has not been created by extracting a file to the destination.

for the record, the code is this:

  File newLocationParentDir = newLocationFile.getParentFile();
  newLocationParentDir.mkdirs();
  if (!newLocationParentDir.isDirectory()) {
      throw new Exception("Failed to create new parent directory for raw file [" + newLocationFile + "]");
  }

in org.rhq.core.util.updater.Deployer.extractZipAndRawFiles

This problem can be averted by getting the canonical path from the location:

   newLocationParentDir.getCanonicalFile().mkdirs();

There are several calls to mkdirs() in this class - will have to examine all of them to see where this problem also occurs.

it turns out this has opened a pandora's box.

I should have written the bundle stuff to disallow using ".." in the rhq:file destination attributes.

For one, this is allowing you to deploy/overwrite files outside of the bundle destination directory. This technically isn't a major problem because we allow you to do this anyway if your destination attribute uses absolute paths (and thus you can write files anywhere the agent has file permissions).

But the real problem I am hitting is that if you use ".." in RELATIVE paths, you are moving outside of the destination directory. The major problem I see is that if we need to BACKUP these files, we can't put them under .rhqdeployments/backup directory. This is where we backup files found in the dest dir, but if you use ".." in the relative paths, this potentially takes you out of the backup directory.

For example:

The normal, common use case for rhq:file is this:

<rhq:file name="app.properties" destinationFile="app.properties" />

where the relative path is "app.properties". If, during a bundle upgrade, that file needed to be backed up when deploying bundle deployment #1, we'd put the backup copy in:

<bundle-dest-dir>/.rhqdeployments/1/backup/app.properties

Now, using the example found in this BZ description:

<rhq:file name="app.properties" destinationFile="../../conf/app.properties" />

That is a relative path, too. If, during a bundle upgrade, that file needs to be backed up, notice how this is a problem - where do we put the backup file?

<bundle-dest-dir>/.rhqdeployments/1/backup/../../app.properties

whose canonical path is:

<bundle-dest-dir>/.rhqdeployments/app.properties

THAT isn't what we want. Take it to the extreme:

<rhq:file name="app.properties" destinationFile="../../../../..conf/app.properties" />

would have a canonical path of of the parent of the bundle-dest-dir itself!

So clearly, this isn't going to work. We can't backup files with relative paths that have ".." in them.

I may need to alter this such that if a relative path has ".." in it, we store it in the ext-backup location (which is used for destination file paths that were absolute in the recipe, like:

<rhq:file name="app.properties" destinationFile="/opt/app.properties" />

we'd store this in:

<bundle-dest-dir>/.rhqdeployments/1/ext-backup/opt/app.properties

I'm not sure what would happen if I back up files specified with relative paths in the ext-backup location, but if that doesn't work, the only other option is to just not backup the files, and warn the user that if they want to rollback the bundle to the previous version, they will lose some data because we can't backup files with "..".

Well, I lied - there is another alternative. You could write your bundle recipe with the dest dir as the top most directory that you plan on storing relative paths. So, if your file path in a recipe is "../app.properties", your destination directory should be the parent directory of what you specified, and your recipe could then include "app.properties".

Two problems to overcome if the file has ".." in its path:

1) if the file is actually above the destination directory, it isn't really considered a "relative" file or one that is under destination directory. We MUST treat it as if it was specified via an absolute path (which means we treat it like an external raw file, not one that belongs under dest dir).

e.g. this happens if destination dir == "/opt/jbossas/server/default/deploy" and rhq:file destinationFile == "../../conf/app.properties"

2) if the file still remains under the dest dir, we still must extract out the ".." but if we do, the Deployer class breaks (the backup stuff doesn't work and it gets confused and thinks it needs to delete the file). We need to enhance Deployer so it normalizes the path so ".." are removed, but yet remains a relative path so we can treat it as any relative path

e.g. this happens if destination dir == "/opt/something" and rhq:file destinationFile == "subdir/../conf/app.properties"

[note: why someone would do this, I don't know. but because I'm paranoid, I'll assume someone out there will find a need to specify the file path like that, so I will attempt to support this]

Created attachment 740225 [details]
patch for fix

attached a patch that should fix this. I have a new unit test class (not in the  patch) that shows this working. Once I verify this more with additional testing, I'll commit this patch along with tests.

git commit to master: 8ae20bd510aa660e94f70cad95fc680fd0dedd47

As this is MODIFIED or ON_QA, setting milestone to ER1.