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.
Note that implementing this wish, seems to solve this bug http://bugs.kde.org/show_bug.cgi?id=89364 about non-image files being used for the calculation of the album date.
To address this bug and http://bugs.kde.org/show_bug.cgi?id=151317 for new users: couldn't we simply: A) Do not include - any files whose mime-type is not listed - any directories starting with . In a first step, no changes to the database will be done, if one changes the files in the mime type list. By this there might be file types in the database which would not be imported for a new directory. But that's not a real problem. B) In a second step one would have to think about the removal of file from the database. This could indeed be done within the context of the usual scan on startup (However, a different message should be given, because the files themselves normally will still exist on the hard-disk). Also: if the user does not do the scan on start-up, where should one place such an update? If this is implemented, a warning when changing mime-types of files which exist in the data-base has to be given. So A) seems easy to me and address quite a few issues while B) is more complicated (and needs some more thought to do it right), as it deals with a clean-up in the database ... I am not sure how the suggestion http://bugs.kde.org/show_bug.cgi?id=123097 can be optimally integreated in this scheme. Of course an .ignore file in a directory sounds like a nice general approach to exclude any type of directory. However, for the example given in that wish of thumbnail files generated one might forget to add that .ignore file.
Marcel, With 0.10.0, this report is solved. right ? Gilles
2.0.0-rc is out, please re-open if needed