Re: Contributing code to Deja Dup

[David Cook <kingandcaptain gmail com>]

Darn keyboard shortcuts...

Oooo, so I just tried to mount two volumes with the same label. I already had "Media0", so when I mounted another volume with the same label, it was mounted as "Media0_" in Debian Wheezy. Well, at least it shows up as "Media0_" in the "/media" directory. If I do a "blkid", its label of course is still "Media0". 

That would mean that the first volume mounted was the authoritative one... as it would be the one in the right spot.

I was able to forcibly mount the second one overtop of the first one using root to run "mount". I think with /etc/fstab/ it will usually take the first entry and ignore the second.

Hmm... looks like both BackendFile.vala and ConfigLocation.vala use UUID. And it looks like UUID is bound up in there pretty good.

I'm not really sure what the best solution would be. 

I've been thinking about trying out obnam or writing my own script to use duplicity directly, but I would love to find a solution with Deja Dup.

How does BackendFile.vala fit into the bigger picture? I suppose it wouldn't do to be able to mount and write out to two disks at once (that runs into the same issues we've discussed before). 

Anyway, have to head off to sleep. Not sure what the best idea is...

Admittedly, the more I think about automated backups, the more puzzles I find. I think Deja Dup and duplicity can be perfect for user backups though, so I'd love to find a solution to this. (I can then think about ways of backing up system files securely :P.)


P.S.

Actually, now that I look at 20.2 (Wheezy), 30 (Trusty), and 30.2... I notice lots of differences. 20.2 has a S3 location but 30 doesn't. 30.2 seems to have a backend for Google Drive which would be handy, but I haven't seen it in any past versions.

On occasion, I think about using cloud-based backups...

On Fri, Dec 12, 2014 at 11:31 PM, David Cook <kingandcaptain gmail com> wrote:

Replies inline as well :). Sorry for the delay!

On Sun, Dec 7, 2014 at 3:41 PM, Michael Terry <mike mterry name> wrote:

Settings are stored in gsettings.  This goes back to the "pathless" thing I was talking about.  Basically, when you tell gsettings what your settings are like (boolean, with this name, etc), you can also assign it a standard path like "/org/gnome/deja-dup/automatic-backup".

But if we did profiles, we'd need to rejigger that to not have a standard path but be assigned dynamic paths like "/org/gnome/deja-dup/profile1/automatic-backup" or some such.  And then probably one standard path like "../deja-dup/profiles" to list the profile names so we knew which paths to examine.

All that isn't particularly hard.  But it would need doing and migration from old to new would need to be done.

Ahhh! A little run of "gsettings list-recursively org.gnome.DejaDup", and now I think I understand what you're saying better. The path seems necessary though, especially when you're saving to an internal disk, but even when you're saving to an external disk. The problem I see is mostly "name" and "uuid", as they're "too unique".

 

We used to have complicated/clever logic for this.  But I ended up just simplifying it to ~3 months (84 days really).  Configurable by a non-advertised gsettings key. 

Hmmm, is it "full-backup-period 90"? I see this in Deja Dup 30.0 (Ubuntu 14.04) but not in Deja Dup 20.2 (Debian 7).

GLib will tell us if a path is mounted or not.  I don't think the user would need to think about how best to choose a location.  I think this would fall under the "seamlessly do what is right" column.

ASSUMING that all modern distros automount using the UUID in the path, normal users that haven't touched anything would get historic, normal behavior.  Only users that have futzed with fstab would get different behavior.  And I think this different behavior would be what that class of users would expect/want.

I think you're right. When a person plugs in an external drive, they'll choose that location and then it should be peaches.

As for the automounting, I played around on Debian with a fat32 USB, a ntfs USB, and an ext4 USB, and they all automounted using their "Label" in the path. 

I just formatted a USB and removed its label, and it automounted using its UUID instead.

Maybe it makes sense to store the UUID but have Deja Dup set up so that more technical users can remove it and just use Labels. 

 

So separately from the whole issue of profiles or not (which I'm still not sold on), I think this would be a good idea to implement.  It lets us Do The Right Thing without any additional UI complexity (or really, much behind-the-scenes complexity).

The more I think about it, the more I agree about not using profiles, but allowing flexibility with the single backup location.

 

So I think the tasks for this would be:

1) Research state of art in modern distros regarding automount paths.  We would ideally expect them all to use UUIDs in the default paths.

Admittedly, I haven't researched this extensively, but it does seem that it alternates between UUID or LABEL depending on what the device has available. In the event of a UUID in the mount path, that would work fine. In the even of a LABEL, it might be suboptimal, since you might have someone buy 5 of the same device and then accidentally back up to it when they plug it in.

Hmm... what about storing an array of UUIDs? That shouldn't be too hard. I don't know about the source code, but that sounds feasible. When checking the UUID against the path, it would check it against an array instead of a string. That way, you can backup to 2 of those 5 devices which might share the same label name.

Hmm... but specifying that array... not as easy to do in the UI. Unless that's an unadvertised trick. 

Any thoughts you have on that one? 

2) Change the BackupFile.vala file to drop all of its special UUID logic and just use the saved mount point.  This should actually simplify logic!

3) Test it and make sure it does what we expect.

As an added bonus, this would be a relatively simple task to implement as a developer not used to the code base...  :)