duplicity-team team mailing list archive

[edgar.soldin@xxxxxx]

smells like a major rework, touching lot's of internals so it'd be probably a new major release.

..ede

On 11.06.2015 00:29, Kenneth Loafman wrote:
> My only concern is that we tell people to clear their cache to solve problems.  He'll have to handle that seamlessly, probably not in the cache though.  Let me think about it some.
> 
> On Wed, Jun 10, 2015 at 5:15 PM, Edgar Soldin <edgar@xxxxxxxxx <mailto:edgar@xxxxxxxxx>> wrote:
> 
>     just feel that we have many construction sites and bugs already. filing volumes is really none of them ;).. but you are the maintainer, so maintain ahead!.. ede
> 
>     On 11.06.2015 00:02, Kenneth Loafman wrote:
>     > ede, been looking at sqlite myself for the manifest and other problems.  Maybe I need to work with him on this.
>     >
>     >
>     > On Wed, Jun 10, 2015 at 3:34 PM, Edgar Soldin <edgar@xxxxxxxxx <mailto:edgar@xxxxxxxxx> <mailto:edgar@xxxxxxxxx <mailto:edgar@xxxxxxxxx>>> wrote:
>     >
>     >
>     >     do you think that is a good idea? maybe we should discourage him early on. s.b. ..ede
>     >
>     >     -------- Forwarded Message --------
>     >     Subject: Re: [Duplicity-talk] Fwd: AssertionError on every attempt
>     >     Date: Wed, 10 Jun 2015 20:10:36 +0200
>     >     From: Bruce Merry <bmerry@xxxxxxxxx <mailto:bmerry@xxxxxxxxx> <mailto:bmerry@xxxxxxxxx <mailto:bmerry@xxxxxxxxx>>>
>     >     Reply-To: Discussion of the backup program duplicity <duplicity-talk@xxxxxxxxxx <mailto:duplicity-talk@xxxxxxxxxx> <mailto:duplicity-talk@xxxxxxxxxx <mailto:duplicity-talk@xxxxxxxxxx>>>
>     >     To: Discussion of the backup program duplicity <duplicity-talk@xxxxxxxxxx <mailto:duplicity-talk@xxxxxxxxxx> <mailto:duplicity-talk@xxxxxxxxxx <mailto:duplicity-talk@xxxxxxxxxx>>>
>     >     CC: duplicity-talk-bounces+tim=night-shade.org.uk@xxxxxxxxxx <mailto:night-shade.org.uk@xxxxxxxxxx> <mailto:night-shade.org.uk@xxxxxxxxxx <mailto:night-shade.org.uk@xxxxxxxxxx>>, Rupert Levene <rupert.levene@xxxxxx <mailto:rupert.levene@xxxxxx> <mailto:rupert.levene@xxxxxx <mailto:rupert.levene@xxxxxx>>>
>     >
>     >     On 10 June 2015 at 16:16, Tim Fletcher <tim@xxxxxxxxxxxxxxxxxx <mailto:tim@xxxxxxxxxxxxxxxxxx> <mailto:tim@xxxxxxxxxxxxxxxxxx <mailto:tim@xxxxxxxxxxxxxxxxxx>>> wrote:
>     >     > I suspect that this is due to the Google storage back-end having difference
>     >     > constancy guarantees for single objects vs directory listings.
>     >     >
>     >     > See https://cloud.google.com/storage/docs/concepts-techniques#consistency
>     >
>     >     Thanks, that's an interesting link. It's describing Cloud rather than
>     >     Drive, but it wouldn't surprise me if Drive is similar i.e. an object
>     >     store with a filesystem duct-taped on.
>     >
>     >     That makes me think that maximum robustness would be achieved by
>     >     having duplicity reference IDs internally and only use filenames for
>     >     presentation to the user. That sounds like it would need major
>     >     architectural changes though, since the list of IDs forming a backup
>     >     set would need to be recorded as part of the backup, instead of being
>     >     discovered from a directory listing.
>     >
>     >     A halfway point might be to have the client keep its own filename<->ID
>     >     cache in the Duplicity cache directory. Operations would need to query
>     >     the object by ID to validate the cache entry, but I think this would
>     >     allow for strong consistency in cases where the same client is doing
>     >     the accesses (as is the case when an upload is immediately followed by
>     >     a query - different clients are more likely to be separated in time).
>     >
>     >     I can probably have a go at implementing that the next week or two.
>     >     Are there helper functions I should look at for the backend to
>     >     discover where the cache directory for the backup lives? And any
>     >     preferences for the format of the cache file? My personal inclination
>     >     would be to go for sqlite to get all the nice safety guarantees that
>     >     gives over just a pickle/yaml/json/xml/whatever file, but that would
>     >     introduce a dependency.
>     >
>     >     Bruce
>     >     --
>     >     Dr Bruce Merry
>     >     bmerry <@> gmail <.> com
>     >     http://www.brucemerry.org.za/
>     >     http://blog.brucemerry.org.za/
>     >
>     >     _______________________________________________
>     >     Duplicity-talk mailing list
>     >     Duplicity-talk@xxxxxxxxxx <mailto:Duplicity-talk@xxxxxxxxxx> <mailto:Duplicity-talk@xxxxxxxxxx <mailto:Duplicity-talk@xxxxxxxxxx>>
>     >     https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>     >
>     >
>     >
> 
>     --
>     public class WhoDidIt{ // A comment. I love comments
>       private static Person sender;
> 
>       public static void main (String[] foo){
> 
>       sender = new Person();
>       sender.setName(new String[]{"Edgar", "Soldin"});
> 
>       Address address = new Address();
>       address.setStreet("Stadtweg 119");
>       address.setZip(39116);
>       address.setCity("Magdeburg");
>       address.setCountry("Germany");
> 
>       sender.setAddress(address);
> 
>       sender.setMobilePhone(" +49(0)171-2782880 <tel:%2B49%280%29171-2782880> ");
>       sender.setWebSiteUrl(" http://www.soldin.de ");
>       sender.setEmail(" edgar@xxxxxxxxx <mailto:edgar@xxxxxxxxx> ");
>       sender.setPGPPublicKey(" http://www.soldin.de/edgar_soldin.asc ");
>       sender.setGender(true);
> 
>       System.out.println(sender.toString());
>       }
>     }
> 
>