Re: [Duplicity-talk] Re: Re: First restore failing

[Darik Horn]

> Ok. Will look into this bit some more; perhaps the address@hidden is causing 
> problems since urlparse does not support it.

This is indeed the special case that the bundled urlparse_2_5.py handles 
differently for backwards compatibility, vice the standard library.

We may be revisiting the design choice made in Bug #21475 and Patch 
#6300.  In particular, the reported problem can be a side-effect of this 
chunk:

--- urlparse_2_5.py     2007-12-26 05:40:38.000000000 -0600
+++ /usr/lib/python2.5/urlparse.py      2007-10-05 09:15:34.000000000 -0500
@@ -82,7 +82,7 @@
     def username(self):
         netloc = self.netloc
         if "@" in netloc:
-            userinfo = netloc.rsplit("@", 1)[0]
+            userinfo = netloc.split("@", 1)[0]
             if ":" in userinfo:
                 userinfo = userinfo.split(":", 1)[0]
             return userinfo


> (2) The patch must be augmented to properly handle address@hidden style URL:s and 
> any other special handling already done by duplicity.

RFC 1738 prohibits passing a literal '@' character in a user name 
through a URL, but duplicity accepts it to maintain legacy FTP backend 
behavior.  In this case, the '@' should be escaped as %40.

Thus, Thorsten Kampe may get the desired result by trying the unmodified 
urlparse.py and/or escaping the URL parameter like this:

  $ duplicity --no-encryption 
webdav://address@hidden/user.provider.tld/files/backup 
~/tmp/backup