magic-wormhole
magic-wormhole copied to clipboard
magic-wormhole
wormhole send apparently crashes badly on non-ASCII file names
Tested it copying a music directory over to another computer. The messages below are what I received. Tarred the directory up and it sends the tar file fine.
$ wormhole send ~/Music/Quantic/Curao
Building zipfile..
Traceback (most recent call last):
File "/snap/wormhole/14/lib/python2.7/site-packages/twisted/internet/defer.py", line 653, in _runCallbacks
current.result = callback(current.result, *args, **kw)
File "/snap/wormhole/14/lib/python2.7/site-packages/twisted/internet/defer.py", line 1442, in gotResult
_inlineCallbacks(r, g, deferred)
File "/snap/wormhole/14/lib/python2.7/site-packages/twisted/internet/defer.py", line 1384, in _inlineCallbacks
result = result.throwExceptionIntoGenerator(g)
File "/snap/wormhole/14/lib/python2.7/site-packages/twisted/python/failure.py", line 393, in throwExceptionIntoGenerator
return g.throw(self.type, self.value, self.tb)
---
Here is an ls of the directory in question:
$ ls ~/Music/Quantic/Curao cover.jpg Quantic - Curao - 01 Intro.flac Quantic - Curao - 02 E Ye Ye.flac Quantic - Curao - 03 Que Me Duele-.flac Quantic - Curao - 04 Dub del Pacifico (Version).flac Quantic - Curao - 05 Interludio I.flac Quantic - Curao - 06 Se Lo Vi.flac Quantic - Curao - 07 Muévelo Negro (Edit).flac Quantic - Curao - 08 Amor en Francia.flac Quantic - Curao - 09 Ojos Vicheros.flac Quantic - Curao - 10 Nanguita (Edit).flac Quantic - Curao - 11 Dios Promete.flac Quantic - Curao - 12 Interludio II.flac Quantic - Curao - 13 Maria No Me Llevo.flac Quantic - Curao - 14 Interludio III.flac Quantic - Curao - 15 Un Canto a Mi Tierra (Version).flac Quantic - Curao - 16 No Soy del Valle.flac Quantic - Curao - 17 Interludio IV.flac Quantic - Curao - 18 Maldito Muchacho.flac
Happy to try some testing if of interest.
What version of magic-wormhole are you using? And what OS?
We might have managed to fix this in current trunk: could you try doing a git checkout and run from there?
Brian, thanks for the speedy reply.
I am mostly away from my computer this weekend but I will check versions and try your suggestion as soon as I can.
Again, thanks!
Chris Hermansen
On Jul 28, 2017 17:02, "Brian Warner" [email protected] wrote:
What version of magic-wormhole are you using? And what OS?
We might have managed to fix this in current trunk: could you try doing a git checkout and run from there?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/warner/magic-wormhole/issues/233#issuecomment-318787627, or mute the thread https://github.com/notifications/unsubscribe-auth/AHgAnlnj7mg8K9f3KwdVelKHuVtBG7SNks5sSnahgaJpZM4OmI0z .
First part:
I installed wormhole on Ubuntu 17.04 via snappy. "wormhole --version" gives
magic-wormhole 0.10.2+0.g13ff246.dirty
As to doing a git checkout and running from there - I've cloned the git source tree but I'm not clear if I need to do the virtual environment stuff or whether I can just do a build / install, and I can't find anything obvious (to me, familiar-ish with Python but mostly lost in the Python development environment). Any suggestions?
Thanks!
On Sat, Jul 29, 2017 at 7:14 AM, chris hermansen [email protected] wrote:
Brian, thanks for the speedy reply.
I am mostly away from my computer this weekend but I will check versions and try your suggestion as soon as I can.
Again, thanks!
Chris Hermansen
On Jul 28, 2017 17:02, "Brian Warner" [email protected] wrote:
What version of magic-wormhole are you using? And what OS?
We might have managed to fix this in current trunk: could you try doing a git checkout and run from there?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/warner/magic-wormhole/issues/233#issuecomment-318787627, or mute the thread https://github.com/notifications/unsubscribe-auth/AHgAnlnj7mg8K9f3KwdVelKHuVtBG7SNks5sSnahgaJpZM4OmI0z .
-- Chris Hermansen · clhermansen "at" gmail "dot" com
C'est ma façon de parler.
It's basically:
- git clone ...
- cd magic-wormhole
- virtualenv ve
- source ve/bin/activate
- pip install .
The "source" line modifies your $PATH to put the virtualenv's ve/bin in front, so when you run pip install . it's using the virtualenv's pip, which means the wormhole command gets installed into ve/bin/wormhole (and $PYTHONPATH is set too, so it doesn't touch anything outside the virtualenv). It'll prefix a little (ve) to your $PROMPT to remind you which virtualenv is currently active.
You might want to git checkout 0.10.2 before the install, to roll back to the most recent release (before we fixed a unicode problem). You might also want to use a separate virtualenv for each version of magic-wormhole that you try out (use deactivate to reset $PATH and $PYTHONPATH back to their original values). I frequently rm -rf ve the virtualenv when I'm done with them, to avoid confusion.
I spun up a VM and I'm playing around with the snappy tools.. gotta say they're kinda neat! In my experiments so far (on ubuntu 16.04, not 17.04), the snappy-packaged version (snap install wormhole, which I notice is using py2) fails to receive a directory with unicode files, but a virtualenv-installed version (both py2 and py3) works.
I'll experiment with 17.04 next, and I'll try building a snap package myself to see if that affects anything. I'm not surprised that 0.10.2 has this unicode problem, but I am surprised that my virtualenv-exercised tests of 0.10.2 worked anyways. I know this is affected by things like Python's default character encoding for command-line arguments, so it's possible that the Python that was used in the snap package is different than the Python I'm getting with this 16.04 VM.
In the long run we'll need some CI to build the snap packages, which might be the place to control/investigate which Python it gets.
I get this error too. My info: Mac OS 10.12.6 (16G29) magic-wormhole 0.10.2
I can confirm the same behaviour on Linux, magic-wormhole 0.10.3, when part of the path is in Unicode (Greek) and I think I can isolate the cause as follows:
[For the demonstration below, I have created a Unicode containing filename in a Unicode containing path: /home/stamatisxm/abc-αβγ/ABC-ΑΒΓ.txt]
If I pass the absolute filename to wormhole, i.e: ~$ wormhole send /home/stamatisxm/abc-αβγ/ABC-ΑΒΓ.txt : SUCCESS
If I pass the relative filename from $HOME i.e: ~$ wormhole send abc-αβγ/ABC-ΑΒΓ.txt : SUCCESS
If I am inside the directory that contains the Unicode characters and pass just the filename, i.e: ~/abc-αβγ$ wormhole send ABC-ΑΒΓ.txt : FAILURE
If I move the file into $HOME and do the same as above: ~$ wormhole send ABC-ΑΒΓ.txt : SUCCESS
The above lead me to speculate that the "exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xce in position 19: ordinal not in range(128)" error message appears when our current path ($PWD) that we invoke wormhole from, contains Unicode characters in its name and is NOT related to the Unicode characters in the pathname/filename argument per se. - HTH
I can't seem to replicate your FAILURE on both 0.10.2 and 0.10.3 (on linux):
(.venv) /o/テ/abc-αβγ >>> (.venv) pwd
/opt/テスト/abc-αβγ
(.venv) /o/テ/abc-αβγ >>> (.venv) wormhole send ABC-ΑΒΓ.txt
Sending 5 Bytes file named 'ABC-ΑΒΓ.txt'
On the other computer, please run: wormhole receive
ammgws Thanks for replying with your findings. Since you pointed out that you couldn't replicate my FAILURE case I did a little digging around and removed magic-wormhole from pip (which I had it installed with) and this time reinstalled it through the package manager on Debian 9 and voila!!! it works flawlessly now!
I think that when installed with pip it tries to use Python 2.7, hence the problem with the Unicode in $PWD. On the other hand, through apt, it installs some Python 3 libraries and works as expected.
I think that when installed with pip it tries to use Python 2.7, hence the problem with the Unicode in $PWD. On the other hand, through apt, it installs some Python 3 libraries and works as expected.
Yes, on Debian pip is for /usr/bin/python and pip3 is for /usr/bin/python3. [edit: fix quotes]
It seems like it would be easy to resolve this bug by somehow instructing PyPI to only distribute the Python 3 variant.
