Re: Contributing code to Deja Dup

[David Cook <kingandcaptain gmail com>]

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...  :)