This is definitely not a file ordering problem, because the sample tarballs have a single file inside a directory inside a directory. The order for that will always be (I think) the parent directory, the directory inside the directory, and then the file. The problem here is gzip, not tar, when invoked without -n option. Attached you will find two different tarballs with the same contents, extracted from one of the cases where t15-dupes.sh failed. If you run "file" on them you will see this: [...] last modified: Wed Aug 17 12:31:46 2016, from Unix [...] last modified: Wed Aug 17 12:31:47 2016, from Unix So for the test to be successful, the tarballs have both to be created in the same one-second interval. That's why this usually succeeds on machines which are fast enough, but not always. Suggested fix: When creating the tar.gz, gzip should run with -n. This could be done with GZIP environment variable, but I think it's deprecated. It would be better if there was a way to tell tar to pass -n to gzip. Then there will be no embedded dates in the tar.gz and they will always be identical, no matter the second in which they end being created. Thanks.
Attachment:
skywalker1-build-backup-manager-0.7.12-t-testdir.20160816.master.tar.gz
Description: application/gzip
Attachment:
skywalker1-build-backup-manager-0.7.12-t-testdir.20160817.master.tar.gz
Description: application/gzip