I appreciate the reply az. I don't think you're correct. I forgot to mention that the first file actually does make it to the destination despite the false error from duplicity. And indeed, it is a false error, because there is no permission problem here.
After more tests, I can see that something in duplicity is timing out. I'll explain: Duplicity aside, if a 50mb file is simply copied from the cloud to a local folder, the transfer takes ~5 min on my connection. Then when the same file is uploaded back to the cloud, the prompt returns /instantly/. It is physically impossible for the upload to happen that fast. This means that whole 50mb file is being cached by davfs2, and other commands touching the remote filespace are forced to wait in a queue. To confirm this, a simple "ls" command was given upon the instant return of the prompt (after starting an upload), it takes a staggering ~5 min for the "ls" command to return. Now to correlate this with Duplicity-- the first 50mb file is instantly uploaded as far as duplicity knows (but in reality the upload is backgrounded and holding up any command concerning that cloud space that may follow). What duplicity does not know is that when it tries to do anything with that file location after the upload begins, the next command will take ~5 min to process, even if it's a command that would in itself normally be very quick. As a hack, I suspect I can work around duplicity's false error by turning off caching in davfs2 (assuming that's possible), or perhaps make the files small enough that the delays will be less than the timeout threshold. However, this will remain a stumbling block for other users. At a bare minimum, I would suggest at least correcting the error message, so that it states that it timed out instead of erroneously citing permissions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
