Does not work with binary files.
Closed this issue · 4 comments
If you split a binary file with:
split -b 200 binary.file
and then
cat x* > binary.file.out
and run
md5sum binary.file binary.file.out
they are the same.
The doing the same with the plugin does not result in the same md5sum.
Thanks for reporting the issue. I have confirmed the unexpected behavior you describe. What is happening, I think, is that the filesystem does not provide a listing of a directory's files in the order that is expected, so the output file contains all of the parts but not in the right order.
As a workaround, you can list the files explicitly, like this:
<execution>
<id>binary-files-test</id>
<phase>process-test-resources</phase>
<goals>
<goal>cat</goal>
</goals>
<configuration>
<sources>
<fileset>
<directory>${project.basedir}/src/test/input</directory>
<includes>
<include>bin/xaa</include>
<include>bin/xab</include>
<include>bin/xac</include>
<include>bin/xad</include>
<include>bin/xae</include>
</includes>
</fileset>
</sources>
<outputFile>${BinaryFilesTest.outputFile}</outputFile>
</configuration>
</execution>
...instead of using a wildcard pattern like <include>bin/x*</include>
.
Being able to use the wildcard pattern is a feature I would like to support, though, so I will try to think of a way to do that.
P.S. I don't think the problem is that the files are binary -- I think it would probably concatenate text files in an unpredictable order too.
I released a fix for this as of commit af0a7cd. It be available as version 0.4 when it makes its way through the Sonatype queue. Use the <sort>alphabetical</sort>
within your <fileset>
element to sort the included files alphabetically. (This is the behavior that the shell induces when you execute cat x* > binary.file.out
.)
Awesome! I will give it a try. Thank you for your quick response!
As a workaround, you can list the files explicitly, like this:
I was able to confirm that this does fix the issue as well.