Re: Contributing code to Deja Dup

[Michael Terry <mike mterry name>]

Replies inline!  I chopped out a lot of stuff that I didn't need to reply to.

On 3 December 2014 at 02:58, David Cook <kingandcaptain gmail com> wrote:

I see how the complexity could easily grow. That returns it back to the profile idea, I suppose. Where are the settings stored at the moment? Does that create an obstacle? I want to say I checked once using 'dmesg', but I can't recall now. While I use Linux as my main operating system, the majority of my knowledge is in web development, so I'm that familiar with how the DE actually works.

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.

 

> 4) You ask about the timing of when to do full backups.  That we'd get for free.  Deja Dup looks at what's in the backup location already and decides if it has been too long since the last full backup.

>

When does it decide that it's been too long though? Is it based on time or the number of backups or something else?

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.

 

> 7) One thought is that we could get most of what you want "for free" for a certain class of users if we simply looked at the mount path instead of the UUID (which as you guessed is what we currently do).  The UUID logic was written back before most distros automounted by UUID (how widespread is that now?).  My original goal was just to make sure that you never accidentally triggered a backup by plugging in some thumb drive, instead of your backup drive.  But if we used mount path, we'd get UUID logic for free nowadays, but we'd also cater to people that had custom fstabs that put both drives in the same mount, right?  That's what you originally tried to do, before realizing Deja Dup was using UUIDs?  Only really a solution that unblocks the technical users.  But a far easier fix at least.  Also wouldn't help with any other kind of backup locations (like remote), but I think that's a less common request than "multiple backup drives" which seems to be fairly common -- I guess people take one drive off-site and rotate every now and then.

>

Yeah, using the mount path rather than the UUID would definitely work for me, but would be catering to more technical users using custom fstabs.

Mmm. The mount path idea would only work if we were able to tell if something were actually mounted to the path. Otherwise we could get spurrious errors or filling up a local folder by accident.

I wonder how it would look from a user perspective as well... it might not be obvious to a regular user how to best choose a location.

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.

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

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.

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

-mt