[Digikam-devel] [Bug 145743] New: only include displayable files in database

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145743         
           Summary: only include displayable files in database
           Product: digikam
           Version: unspecified
          Platform: Debian stable
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: arnd.baecker web de


Version:            (using KDE KDE 3.5.5)
Installed from:    Debian stable Packages

Presently files of arbitrary type are included in the database. 
This should be changed so that digikam only manages those files 
which are registered in the MIME Types configuration of digikam.

Background:
I would like to add additional information/notes/... within
the image folders (for example like *.txt, *.html, *.gpx,
*.kml, *.pto, ... files).
Such files, however,  lead to messages like

  Cannot load metadata using Exiv2
  (/home/fotos/Pictures/2007/2007_04_a/tst.gpx: The file contains
  data of an unknown image type)

This topic was discussed on digikam-devel, which summarizes 
to the following proposed solution:
- ignore files whose extension is not included in any of
  the listed Mime Types
- if the users changes the MIME type settings, 
  a clear warning will be given, if one of the removed files types
  is presently in the database.

Some details of the discussion:

Possible solution: Just completely ignore files
whose (lower-case) extension is not included in any of
the listed Mime Types?
This would be possible already now and imply no change
in the database.

Only for files which are already in the database
(and not listed in the Mime Types) it would mean that
they just stay in the database
(which would be no real problem, I think ...)

Comment of Marcel:
|In the current situation, any file is inserted in the DB, and only when 
|reading from the db, files are filtered by filename.
|It is of course easy to do the filtering when inserting into the DB. After the 
|initial scanning at startup, new files will be added and files which do no 
|longer belong to the mime type list are removed. This also solves the problem 
|with wrong album high/low/mean dates.
|
|I see one major problem here:
|A user might by chance or misunderstanding remove e.g. ".jpg" from the 
|mimetype list. Suddely all his photos are gone, which is no problem they can 
|be rescanned. But all tags and ratings are lost!! (unless written to file - 
|assume it is not).
|
|We need to prevent this.
|One possibility is a hardcoded list of image formats that are supported. I 
|cannot see any indication for removing .jpg from the mime type list.
|Hm difficult. A positive list of added formats, a negative list? Or keep it as 
|it is, develop another approach?

Gilles on this:
|Right Marcel. And this problem is not relevant of JPEG files only. RAW
|files for example can be tagged intensivly. For example i have an huge
|tagged collection of MRW files on my main computer...
| 
|Why not to ping users with a confirm dialog when the users change
|something in type mime dialog ?

That sounds like a good solution!
A very very clear warning, if one of the removed files types
is presently in the database, should do the job.