cache misses with follow up backups? #88
Description
I have a single backup archive in a remote attic repository. When creating a new backup set, it looks as though the cache is not working for some files - I know that files under 4096 bytes are ignored in recent changes, but this seems to affect larger files. The reason I noticed was I thought the second backup was going a bit slow on files that hadn't changed:
eg:
this is listed in the first backup set:
# attic list malus::malus-2014-05-27 | grep "home/amr/site/source/acar/magscans/acar_1992_04_09-04/0001.jpg"
-rw-r--r-- ftp staff 172906 Apr 18 2005 home/amr/site/source/acar/magscans/acar_1992_04_09-04/0001.jpg
then when doing a second backup strace shows
lstat("/home/amr/site/source/acar/magscans/acar_1992_04_09-04/0001.jpg", {st_mode=S_IFREG|0644, st_size=172906, ...}) = 0
write(1, "/home/amr/site/source/acar/magsc"..., 64) = 64
open("/home/amr/site/source/acar/magscans/acar_1992_04_09-04/0001.jpg", O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=172906, ...}) = 0
ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff2766de90) = -1 ENOTTY (Inappropriate ioctl for device)
fstat(6, {st_mode=S_IFREG|0644, st_size=172906, ...}) = 0
lseek(6, 0, SEEK_CUR) = 0
brk(0x39db000) = 0x39db000
brk(0x43db000) = 0x43db000
read(6, "\377\330\377\340\0\20JFIF\0\1\2\1\1,\1,\0\0\377\355\26LPhotosho"..., 10485760) = 172906
read(6, "", 10309632) = 0
read(6, "", 10465280) = 0
brk(0x2fdb000) = 0x2fdb000
close(6) = 0
Files that get a cache hit just do the lstat/write/getxattr calls, but it seems many are being re-read even though they haven't changed. I've only just started looking at the python but something is wrong here, and its causing the second backup to take much longer than it should. Any help debugging this would be much appreciated or perhaps I have misunderstood how the caching works. thanks.
I'm running 0.12 dev (git 3ab53b7)