Bug 318902 - very long lasting scan for new items after copy of sqlite3 database
Summary: very long lasting scan for new items after copy of sqlite3 database
Status: RESOLVED NOT A BUG
Alias: None
Product: digikam
Classification: Applications
Component: Database-Scan (show other bugs)
Version: 3.1.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-26 07:57 UTC by krienke
Modified: 2017-08-18 09:09 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 3.2.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description krienke 2013-04-26 07:57:41 UTC
I have two linux (opensuse12.3, KDE 4.10.2) systems. On both systems I sync all of my photos (rsync) as well as digikams database. I use the same version of digikam on both systems at the moment 3.1.0.  The photos are stored in exactly the same path on both systems. 

In order to get this working I inserted a special entry a long time ago in digikams database in table AlbumRoots:

sqlite> select * from AlbumRoots;
id|label|status|type|identifier|specificPath
1|photos|0|1|volumeid:?path=/home/krienke/lib/photos|/

/home/krienke/lib/photos is the Albumroot on both systems. The only difference is that on one system its a directory on the second its a symbolic link. However this did not change in the past 5 years and this setup used to work really fine.  

Since about version 3.0 I have a strange problem on the sync destination .  After I have synced say from system A to system B and then start digikam on system B digikam searches for new entries as usual. But the unusual thing is that this search takes at least 30minutes on a 4 core Core-i5 with 8GB RAM and about 2000 photos. The disk is very busy in this time. It only takes such a long time after a sync process else the search for new entries is done after a few seconds.

The search for new entries is actually not needed at all in this case because everything is in sync because rsync creates an exact copy.

Reproducible: Always

Steps to Reproduce:
1. Rsync all photos and databse from one to another system
2. start digikam on the destination system
3.
Actual Results:  
digikam takes a very long time searching for new items
Comment 1 Marcel Wiesweg 2013-04-26 17:38:29 UTC
Does a sync update the modification time in the file system?
Comment 2 krienke 2013-04-29 06:12:57 UTC
Just tested what files are modified by the sync (ls -lR). It is as it should be, only the files that really changed on the source side as well as the parent directory show a change in mtime on the destination side as well as the digikam database file. All other files and directories remain untouched.

After the sync I started an strace  -v -f -F -e 'trace=open' on the digikam process that again started a long lasting search for new entries. I could see that each and every photo is beeing opened not only the modified ones or those in a directory with a changed mtime.
Comment 3 krienke 2013-04-29 08:20:36 UTC
I checked again and my problem is related to mtime.

In my first test I tested only what changes on  the destination side when I run a sync from source to destination. This was ok. However I now compared the modification time of the files on source and destination and there were many files that were not identically.

After fixing this sync problem, after a sync digikam still looks for new files on the destination but much faster (about 15sec) which is ok.

Thanks for the mtime-hint
Rainer