duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Schuller
Subject: Re: [Duplicity-talk] Re: Re: Re: First restore failing
Date: Sun, 9 Mar 2008 15:14:18 +0100
User-agent: KMail/1.9.7

> > What I still don't get for the life of me, is why it is behaving as
> > if 'https' was an unknown scheme...
>
> Well, what determines if something is a known scheme or not?

urlparse has an internal list of various attributes associated with certain 
schemes. One of these attributes determines whether the component after 
scheme:// is a hostname. This is determined by affirmatively stating that a 
particular scheme is of this form; the default otherwise is to treat it the 
other way around.

Without actually looking into the standard, I am personally slightly peeved by 
this behavior and would prefer to have unknown schemes default to assuming a 
hostname, since this is much more common.

However, the bundled version of urlparse_2_5 *does* have https listed:

uses_netloc = ['ftp', 'http', 'gopher', 'nntp', 'telnet',
               'imap', 'wais', 'file', 'mms', 'https', 'shttp',
               'snews', 'prospero', 'rtsp', 'rtspu', 'rsync', '',
               'svn', 'svn+ssh', 'sftp']

And this is confirmed to work over here and for you, based on your previous 
input. Yet for some strange reasons this seems to fail when duplicity runs. 
The output for you after applying the original version of my patch was:

webdav path decoding and translation:
https://server/backup/ -> //server/backup/
https://server/backup/duplicity-full-signatures.2008-02-27T16%3A54%
3A29Z.sigtar.gz -> //server/backup/duplicity-full-signatures.2008-02-
27T16:54:29Z.sigtar.gz

The fact that "https://server/backup/"; translates into "//server/backup/" 
being interpreted as the path, seems consistent with https being unknown by 
the urlparse module. I really don't see how the problem can be in the 
backend. With the latest version of the patch:

                raw_filename = self._getText(href.childNodes).strip()
                parsed_url = urlparser.urlparse(urllib.unquote(raw_filename))
                filename = parsed_url.path
                log.Debug("webdav path decoding and translation: "\
                          "%s -> %s" % (raw_filename, filename))

In other words, other than URL unquoting, the raw filename is passed directly 
to urlparse(), and the 'path' property is accessed thereafter.

So I am at a loss, provided that the scheme in the original url truly is 
exactly the string "https" and nothing else.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]