I think there are two issues going on here. The first issue that occurs during or right after a file is uploaded. The python httplib code does a call to get a response from the server for the packet sent. It appears there may be a transient error such a socket timeout or something up with the response header. When this error occurs, the httlib2 code then does a retry of the original PUT. This is where the second issue occurs.
When this occurs, we always get back a '400 Bad Request' error from the server. It is not clear to me why this error occurs since the same exact PUT is used from the first try. Will probably need to ask someone from the Ubuntu One team why the server thinks the second (and subsequent) retries are malformed when the server doesn't think the first one is. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to deja-dup in Ubuntu. https://bugs.launchpad.net/bugs/1161599 Title: Backup to Ubuntu one failed, after 5 attempts status 400 bad request Status in “deja-dup” package in Ubuntu: Invalid Status in “duplicity” package in Ubuntu: Confirmed Bug description: On Raring using deja-dup to backup to Ubuntu one, when I add a particular git repository to the folders to backup and then start the backup, the process sits for some minutes at the start of the upload operation and then fails with a popup "Backup Failed. Giving up on request after 5 attempts last status 400 bad request". The progress bar does not get started as far as I can see. While it is saying that it is uploading I can see in System Monitor that data is being continuously sent, but after the failure there are no new files on U1. By a process of elimination I determined that it is the objects directory (which itself contains a large number of subdirectories each containing a number of small files) that is causing the problem. I attempted to determine whether it was a particular file or folder that was causing the problem but it seems not to be consistent. I thought that I had found a particular subfolder causing the problem, I cleared .cache/deja_dup, and then it accepted that folder. However when I then put back the rest of the subfolders it failed again. I copied the complete git repository to another machine (running up to date Ubuntu 12.04) and backing up from there (to a different U1 account) deja_dup has no problems. I also notice that on Raring it always takes a long time in the verification phase even when only a trivial change has been made. It is as if it is downloading the whole repository, but whether that is a related problem I do not know. ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: deja-dup 25.5-0ubuntu1 ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4 Uname: Linux 3.8.0-15-generic i686 ApportVersion: 2.9.2-0ubuntu5 Architecture: i386 Date: Thu Mar 28 20:28:06 2013 InstallationDate: Installed on 2012-08-01 (239 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha i386 (20120730.1) MarkForUpload: True SourcePackage: deja-dup UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/deja-dup/+bug/1161599/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
