Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
c.put confusion about string vs file-like object in local #1749
According to transfer.put() docs, I should be able to either provide local path to a file (as a string), or a file-like object.
When using the former (string), I can specify in the
But when I try to do the same (
It fails specifically on
The solution is to always provide the full path, e.g.
But that is inconsistent with the docs and examples.
Finally, having to provide the full path to
Looking at this now, I'm not actually sure the issue is assumption of FLO, I think it's instead just a straight up lack of implementing correct remote path munging - in other words, we're asking the SFTP server to open the directory as a file to write, instead of tacking on the local file's basename to the remote directory path.
Partial debug log from Fabric's end:
Then part of the traceback shows we're throwing that directory path into CMD_OPEN, in
t, msg = self._request(CMD_OPEN, filename, imode, attrblock)
Which eventually hits that same file/class' error handling around what the SFTP server said was wrong with the IO operation (which is why it's just "Failure" because of course it is...AFAIK that's OpenSSH's fault.)
Anyway, time to write some tests to prove this and then figure out if it's a logic oops (I thought we were constructing an appended path at some point) or an actual straight up missing piece of functionality.
While I'm in here, wondering how to handle FLOs too, in the case where remote path is a directory.
In v1, we looked at FLOs'
Anyway, so here in v2 we have the opportunity to address that for reals, or to just throw an explicit exception saying "whoa hey you need to give a non-directory remote file path for these". Probably both, since not all FLOs necessarily have the name attribute anyways.