Summary: | very long lasting scan for new items after copy of sqlite3 database | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | krienke |
Component: | Database-Scan | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED NOT A BUG | ||
Severity: | normal | CC: | caulier.gilles |
Priority: | NOR | ||
Version: | 3.1.0 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 3.2.0 |
Description
krienke
2013-04-26 07:57:41 UTC
Does a sync update the modification time in the file system? 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. 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 |