Post

2 followers Follow
0
Avatar

file.Folder in XL Deploy uses tar command from path. Can result in variable results

Just wanted to inform you guys about this pitfall:

overthere-2.4.0.jar uses this command to unpack a folder on destination:

 

    public static final String DIRECTORY_COPY_COMMAND_FOR_UNIX = "directoryCopyCommandForUnix";

    public static final String DIRECTORY_COPY_COMMAND_FOR_UNIX_DEFAULT = "tar c -C {0} . | tar xm -C {1}";

 

Depending on which tar that happens to be in path, the outcome varies. On our Solaris, the gnu-tar works fine, but the standard tar that comes with the os (in /usr/bin/tar) gives the following error:

 

build 08-May-2014 14:10:59 [ERROR]: com.xebialabs.overthere.RuntimeIOException: Cannot copy [/tmp/ot-20140508T131052278/3dlib] to [/tmp/testDir] on [ssh:sftp://wasadmin@targetServer:22]: tar: tar: /dev/rmt/0/dev/rmt/0: : No such file or directoryPermission denied

 

If anyone else stumble into this error after upgrading to XL Deploy 4.0.0, it is because the overthere-artifact from 2.3.0 (deployit 3.9.4)  to 2.4.2 (XL Deploy 4.0.0) has changed the method uf unpacking.  And the new method is dependent on external tar command. 

 

To reproduce:

* Be the user XL Deploy becomes "overthere"

* Run the command: " tar c -C /tmp/someDir . | tar xm -C /tmp/someTargetDir"

 

If it's the correct tar, your command should just return and what ever was in /tmp/someDir should also be in /tmp/someTargetDir

 

If it's the wrong version of tar, the error will be: tar: tar: /dev/rmt/0/dev/rmt/0: : No such file or directoryPermission denied

 

In my opinion the overthere-artifact shouldn't depend on external commands, and if they do, it should at least be well documented. 

 

We spent a few hours figuring this out by jad-ing the artifacts. 

 

 BTW: It also results in the command: tasks.archive(taskInfo.id) to never finish. Hence the deploy hangs.....

 

 

Bjarte Nilsen Answered

Please sign in to leave a comment.

4 comments

0
Avatar

Seems like it's enough to add the flag -f to the tar command. 

public static final String DIRECTORY_COPY_COMMAND_FOR_UNIX_DEFAULT = "tar cf -C {0} . | tar xfm -C {1}";

 

Bjarte Nilsen 0 votes
0
Avatar

Hi Bjarte,

The usage of the tar command was introduced in XL Deploy 4.0.0 to copy files/directory between directories on a single remote machine without downloading and then uploading them again. But we have indeed found out that the tar command, while always available on Unix systems, does not always behave as expected. On AIX it will sometimes (but not always :-() fail with the following message if you don't supply the f flag:

tar: tape read error: unexpected EOF (errno=1)

 

So for the next release of XL Deploy, scheduled for later this month, we have changed the default directory copy command to the value below, which has been verified to work on AIX, Linux and OS X:

cd {1} ; tar -cf - -C {0} . | tar xpf -

BTW, if you are looking for the source code of the XL Deploy connection library, you can find it on Github as Overthere. This issue is up there as #116.

Finally, if you want to override one of these defaults, you can override them in your synthetic.xml by following the instructions on how to expose Overthere connection properties as hidden properties in XL Deploy.

Regards, Vincent.

XebiaLabs Support 0 votes
0
Avatar

Hi,

On IBM i (AS400) the following command :

tar cf -C {0} . | tar xfm -C {1}

return :

tar: -C: No such file or directory (errno=1)

In fact the arguments -C is unknown...

Regards,

 

 

 

CAPRIO Nicolas 0 votes
0
Avatar

Hi,

We've recently released Overthere 2.4.3, which will be included in the upcoming XL Deploy 4.0.1 maintenance release. The tar command line used to copy files has been verified to work on AIX 7, Linux and OS X.

You can download it from the Overthere community site.

To install:

  1. Stop the XL Deploy server.
  2. Move the file overthere-2.4.2.jar out of the lib directory.
  3. Move the new file overthere-2.4.3.jar into the lib directory.
  4. Start the XL Deploy server.

Regards, Vincent.

 

 

XebiaLabs Support 0 votes