Re: Viewing Contacts

On Saturday 13 December 2008, Anne Wilson wrote:
> On Friday 12 December 2008 18:48:14 Ingo Klöcker wrote:
> > On Friday 12 December 2008, Anne Wilson wrote:
> > > The second thing that seems a cause for concern is that when I
> > > added a record, std.vcf was backed up as std.vcf_5, not std.vcf_1
> > > as expected.  This is nonsensical, both in the context of its own
> > > directory and the context of the original resource's directory.
> >
> > This behavior does make sense if the backups are created in
> > ringbuffer fashion, i.e. the oldest backup is replaced by the new
> > backup and all other backups are left untouched. (Think "Duck,
> > duck, goose" [1].)
> >
> > If the backups were created in "finite queue" fashion then the
> > creation of a new backup would require renaming all other backups.
> > (Think belt conveyor.)
> >
> > Your observation indicates that KAddressBook uses a ringbuffer for
> > the backups.
>
> Ingo - there were no backups in that directory when I made the
> change.  Now there is std.vcf and std.vcf_5.  It still seemed
> illogical to me, so I browsed the directory on an older box, with
> more backups, and was surprised at what I saw -
>
> std.vcf_1		07/07/08
> std.vcf_2		16/09/08
> std.vcf_3		30/07/08
> std.vcf_4		18/09/08
> std.vcf_5		11/07/08
> std.vcf_6		25/10/08
> std.vcf_7		06/07/08
>
> I'm pretty sure that older versions ran the conveyor-belt system, so
> it looks as though the system has changed in recent versions.  This,
> of course, has implications for anyone needing to restore an older
> version, which thankfully is a rare occasion these days :-)

Hmm, I found the following very old backups:
-rw-r--r--  1 ingo users  16557 2006-12-04 19:03 std.vcf_1
-rw-r--r--  1 ingo users  16557 2006-11-28 23:35 std.vcf_2
-rw-r--r--  1 ingo users  16557 2006-11-22 00:03 std.vcf_3
-rw-r--r--  1 ingo users  16557 2006-11-30 00:52 std.vcf_4
-rw-r--r--  1 ingo users  16557 2006-12-01 01:34 std.vcf_5
-rw-r--r--  1 ingo users  16557 2006-11-18 09:03 std.vcf_6
-rw-r--r--  1 ingo users  16557 2006-12-03 23:49 std.vcf_7

So from oldest to newest: 6 - 3 - 2 - 4 - 5 - 7 - 1
I cannot make a pattern of this.

KAddressBook 3.5.10 appears to use two underline characters for the 
backups. For those backups I get:
-rw-r--r-- 1 ingo users 18230 2008-12-12 21:21 std.vcf__0
-rw-r--r-- 1 ingo users 18230 2008-12-12 21:21 std.vcf__1
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__10
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__11
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__12
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__13
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__14
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__15
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__16
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__17
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__18
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__19
-rw-r--r-- 1 ingo users 18230 2008-12-12 21:21 std.vcf__2
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__20
-rw-r--r-- 1 ingo users 18230 2008-12-12 21:21 std.vcf__3
-rw-r--r-- 1 ingo users 18230 2008-12-12 21:21 std.vcf__4
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__5
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__6
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__7
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__8
-rw-r--r-- 1 ingo users 18174 2008-12-12 21:21 std.vcf__9

So the (modification) time does not give any hint as to which backup is 
the most recent one. OTOH, the identical modification time together 
with the file size (backups 0-4 are larger than the other backups) 
indicates that version 3.5.10 uses the conveyor-belt system.


Regards,
Ingo

_______________________________________________
KDE PIM users mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kdepim-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAklDmkoACgkQGnR+RTDgudg78wCdH99KNsSVIWbnRw4F/qm9YkGK
NL0AnAv++wrhzrnCLquTP3SLy+O/4CrP
=SHrD
-----END PGP SIGNATURE-----