"dmedia" in exclude_names but old records synced back from UbuntuOne

Bug #690406 reported by Jason Gerard DeRose
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
desktopcouch (Ubuntu)
New
Undecided
Chad Miller

Bug Description

Binary package hint: desktopcouch

In my dmedia development I often delete my dmedia database to run a manual test from a clean starting point. Stuart Langridge told me about the "exclude_names" trick to prevent a database from being synced with Ubuntu One. This seemed to work fine for a while, but the past week or so I noticed old dmedia records getting synced back from Ubuntu One.

It's easy for me to spot old dmedia records because the _id was formally a sha224.hexdigest() like this:

"_id": "a7b4e4b5c0007d5309602ad07a43de4c56598a1591aa5f0ae3da5a7a"

And now the _id is a base32-encoded sha1 hash, like this:

"_id": "23WRPNDGZ2ZVOURCPDRT2EWJ2PA6VSH3"

This is the paired_server record:

{
   "_id": "d0e038981d4b4c80943313946339ac42",
   "_rev": "11-a72869c97246b597078ac4a9b50630c4",
   "push_to_server": true,
   "ctime": "2010-06-15 16:37",
   "record_type": "http://www.freedesktop.org/wiki/Specifications/desktopcouch/paired_server",
   "service_name": "ubuntuone",
   "pairing_identifier": "40f6173e-75ae-41d4-9bbe-05ecd24f9600",
   "excluded_names": {
       "be08212a-13f9-4189-a5f2-406066574492": "dmedia_test",
       "_order": [
           "be08212a-13f9-4189-a5f2-406066574492",
           "ab9f0f51-1bd7-4f91-ac55-c3806c931ba8"
       ],
       "ab9f0f51-1bd7-4f91-ac55-c3806c931ba8": "dmedia"
   },
   "pull_from_server": true
}

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: desktopcouch 0.6.9b-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-24.42-generic 2.6.35.8
Uname: Linux 2.6.35-24-generic x86_64
Architecture: amd64
CheckboxSubmission: fdbdfcded0c0bb479a6b52e9ec5af131
CheckboxSystem: edda5d4f616ca792bf437989cb597002
Date: Tue Dec 14 15:25:14 2010
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: desktopcouch

Revision history for this message
Jason Gerard DeRose (jderose) wrote :
Revision history for this message
Jason Gerard DeRose (jderose) wrote :

Looking in .cache/desktop-couch/log/desktop-couch-replication.log, it seems that the dmedia DB is being replicated despite being in excluded_names:

2010-12-12 00:04:56,914 DEBUG want to replipull 'dmedia' from static host '40f6173e-75ae-41d4-9bbe-05ecd24f9600' @ couchdb.one.ubuntu.com

Revision history for this message
Chad Miller (cmiller) wrote :

I think I remember this problem as that "exclude_names" should be an actual list instead of a MergableList. That is, the code uses set membership tests which would find the keys of a dict, not the values of a dict. So, the trick is to update the record to contain a list of items, not a dict-like structure. I'd use futon, if it's a one-off deal.

Jason, did you create it this way,

        excl = desktopcouch.replication_services.ubuntuone.ReplicationExclusion()
        excl.exclude("dmedia")

?

This functionality isn't advertised and wasn't used anywhere outside the tests for quite a while. I wouldn't be surprised if there's something I missed.

---

Incidentally, there's an exception in there that looks like the data file of your dmedia DB is corrupted on our server. Would you like us to remove that file?
ServerError: (500, ('json_encode', '{bad_term,<0.26667.4>}'))

Changed in desktopcouch (Ubuntu):
assignee: nobody → Chad Miller (cmiller)
Revision history for this message
Jason Gerard DeRose (jderose) wrote :

So when Stuart walked me through this originally, I just edited the record from within Futon. I made "excluded_names" a regular list and then desktopcouch at some point changed it into a MergableList.

Yes, please remove the corrupted dmedia DB.

I thought Stuart said there was some way for me to delete a DB in UbuntuOne, using some extra command line tool or something. That ring a bell?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.