A short story. For years I've not only accumulated thousands of pictures (around 50, to be more precise) but also schemas on how to sort those photos. After a long internal debate, I settled for the following one (for the moment, that is):
- Pictures are imported from the camera's SD via a script, which:
- Renames them from
DSCXXXXX.JPGto a date based file name, using the picture's exif data.
- (Hard) links them to a year/month based dir structure.
- Renames them from
- Later, pictures are sorted by hand into thematic dirs for filtering.
- The year/month tree is handled with
- Pictures are filtered into their final destination sorted by category, year and
event (for instance,
- Pictures are also (hard) linked into a tag based dir structure, using nested tags.
So, the whole workflow is:
SD card --> incoming/01-tmp -> incoming/02-new/theme -> incoming/03-cur --> final destination `-> year/month `-> tags/theme/parent/child
The reason for using hard links is the following: I
rsync everything to my home
server, both as backup and for feeding the gallery(s) there. Because pictures are
moved from one location to another until they reach their final destination,
retransmits the picture in its new location and then deletes the old one (I'm using
--delete-after, to make sure the backup does not loose any picture if the transfer
is stopped). This leads to useless transfers, as the picture is in the remote.
I played with the idea of using
git or even
git-annex for working around this,
but in the end I decided to (ab)use
rsync's hard link support. Now moving any picture
in the workflow or renaming a category, theme or directory just means creating new hardlinks to the links in the year/month tree
and removing the old ones later, an almost immediate operation. This also helps saving
space and time when implementing the tag based tree.
digikam is good enough to uniquely identify each picture, even when two hard links
point to the same file. This still means the picture appears several times; the
metadata (most importantly, tags) are shared, but each new link
adds load to the
I bit the bullet and sat down to do a last move and be done. I moved the year/month
ByDate/, completely isolating it from the rest of the collection. Then pointed
digikam to only read that, and here's how I did it:
digikam, of course.
- Backed up everything, including both the database, which was in the collection's root, and the
- Modified the latter so it points to the new database location:
[Database Settings] Database Name=/home/mdione/Pictures/ByDate/ Database Name Thumbnails=/home/mdione/Pictures/ByDate/
- Moved the database.
- Changed the collection's root dir in the database:
mdione@diablo:~/Pictures/ByDate$ sqlite3 digikam4.db -- Notice the specificPath is relative to the volume. In my case, the volume is /home sqlite> select * from ; 1|Pictures|0|1|volumeid:?uuid=f5cadc44-6324-466c-8a99-4ede7457677e|/mdione/Pictures sqlite> update set specificPath = '/mdione/Pictures/ByDate' where id = 1; sqlite> select * from ; 1|Pictures|0|1|volumeid:?uuid=f5cadc44-6324-466c-8a99-4ede7457677e|/mdione/Pictures/ByDate
digikamand let it rescan the collection, which recognized the only link to the image and kept the tags.
This worked superbly!
 When I talk about pictures, I'm also including videos.