Fix semi-relative paths in file

[kurtharriger]

Use .getCannonicalPath instead of .getAbsolutePath
Fixes #17

[joegallo]

Seems reasonable to me, thanks for sending us a PR.

@technomancy if you're cool with this, I can merge it and get a new version up.

[technomancy]

Go ahead; seems totally reasonable.

[joegallo]

Alright, great. I'll get this merged up and deployed today.

[joegallo]

Hmmm... I want to know a little more about the use case here. We don't get this change for free, sadly.

In the current scheme of things, if I have a symlink inside my pkg directory, then it'll be magically resolved into the real file at runtime. So I could do something like this, for instance:

cd myproject/pkg
ln -s ~/some-file something

And I'll end up with something included in my tar, and it'll have the contents of ~/some-file.

With this change, however, it doesn't get included as something, but rather as myproject//Users/joegallo/some-file which seems like pretty bad behavior.

Anyway, if the case of symlinks is supported, then we should probably have tests for it (or tests at all), so I'll consider that a takeaway from this.

That said, can you elaborate a bit more on the issue you're seeing so we can figure out if there's a way to satisfy both use cases?

[kurtharriger]

Interesting. We are using lein-tar to to build samza jobs.
This worked fine when we were using java 6, but we added some stuff that required java 7 and apparently when building and testing locally on OS X I was running into the following error extracting the tar when the tar was built with java 7:

lib//Library/Java/JavaVirtualMachines/jdk1.7.0_75.jdk/Contents/Home/jre/../lib/tools.jar: Path contains '..' tar: Error exit delayed from previous errors

I wasn't too sure why lein tar was including this file in the first place, but changing it to use canonical path worked resolved my issue as it normalized the path so it did not have .. in it.

I was curious why this was being included in the first place and I tracked it down to the following dependency:

[org.apache.kafka/kafka_2.10 "0.8.1.1" :exclusions [[com.sun.jmx/jmxri] [javax.jms/jms] [com.sun.jdmk/jmxtools]]]
[jdk.tools "1.7" :scope "system"]

Here this is listed as a scope system and I think it would automatically be in the classpath on other platforms so I was also able to resolve the issue by explicitly excluding the dependency in my project:

[org.apache.samza/samza-yarn_2.10 "0.8.0" :exclusions [org.apache.avro/avro log4j jdk.tools]

Excluding the dependency also resolves the issue, so I don't need this change it just seemed like the right thing to do, but perhaps not. jdk tools is common enough that I thought this might come up again, but maybe excluding it is the best solution here? Maybe lein-tar should exclude system and provided dependencies by default? I suppose one can always use a profile if they want to be more explicit about which dependencies to include and exclude as well.