absolute path in upload does not work

[kulak]

If absolute path is used, then copy does nothing and does not complain:

deploy: desc: uploads files upload:

• src: /tmp/go1.8.linux-amd64.tar.gz dst: $HOME/

[VojtechVitek]

Are you sure it doesn't upload files into: $HOME/tmp/go1.8.linux-amd64.tar.gz?

[jazoom]

Well that answers a question about why my file wasn't being uploaded. I guess it takes the whole path with it. Is there a way to flatten the path and just take the file?

This behaviour is not clear in the docs.

[RussellLuo]

Possible Reason

I encountered the same issue, and maybe I have found the reason.

The following two kinds of tar commands behave differently:

1. Empty --exlcude argument, with a relative path, generates a correct archive

   $ tar --exclude= -C . -czf tmp.tar ./example.txt

2. Empty --exlcude argument, with an absolute path, generates a invalid archive (the issue scenario here)

   $ tar --exclude= -C . -czf tmp.tar /tmp/example.txt

And some system information:

$ uname -v
#143-Ubuntu SMP Mon Aug 29 20:15:20 UTC 2016
$ tar --version
tar (GNU tar) 1.27.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.

Possible Solution

Remove the unnecessary empty --exclude argument:

$ tar -C . -czf tmp.tar /tmp/example.txt

[kulak]

I can no longer reproduce the issue, because I moved to fabfile.org solution. I am closing the issue as it appears to have been fixed.

[RussellLuo]

Sorry, what does "moved to fabfile.org solution" mean? Use Fabric instead of Stack Up?

[kulak]

Yes, I have moved to use Fabric.