For some of my jpeg-files dolphin (kde4.8, ubuntu 12.04) shows 2106-02-07 7:28 as file creation time in the file properties dialog. If nepomuk is disabled it shows the number 4294967295 (which is 2^32-1) in this place which is 2106-02-07 expressed in unix time (seconds since1970).

The latter indicates that this meta data is corrupted and filled with 1-bits only. However I have no idea where this data is stored. It's neither the standard unix modification, change, or access time nor some EXIF or IPTC meta data. Copying these files with cp preserves this data while copying with 'cat foo > bar' does not. So I assume it's some file system data.

The files are stored on an ext3 file system and where once copied from the fat system of a sd card. The 'stat' command also shows the 'birth' of the file but the displayed value is '-' for those files.

This problem is really anoying since searching for today's files in nepomuk also shows these files (several thousand jpegs). It would be nice if someone could tell me where this 'creation date' comes from.

It's stored in the file system, but not ext3. Birth time is suported in ext4. Btw, I didn't known that creation time is supported by Dolphin.

Can you please provide a screenshot of the metadata display?
On my system (which also uses ext4) KDE does not display creation times, so it may be something else you are seeing.

First of all, the filesystem is really mounted as ext3 so it cannot be the ext4 birth time:

Code: Select all

  >cat /etc/mtab
  [...]
  /dev/sda5 /home ext3 rw,relatime,errors=remount-ro 0 0


I'll provide screenshots of the information tab in the file properties dialog with and without nepomuk. Unfortunately the dialog is in german. It's the property named 'Erstellt' which is 'created' in english. If you like I can also provide the file itself. At least gwenview and digikam do not reveal any related time stamps in the exit/ictp/xmp meta data.

@bcooksley: The FAQ says that an admin has to allow the posting of attachments. Can you grant me the permission such that I can upload the screenshots.

cgraeser - for attachments you should use one of the many available free hosting sites (there are sites specifically for text and for images) and place a link to the image or display the image using the img tags

Here you go: The screenshots of the file properties dialog:
with nepomuk enabled
with nepomuk disabled.

I would guess that it's from the Exif data from the jpg file. Strange that it shows Unix time when Nepomuk is enabled (I can also see this on my system).

As I said, I can't find anything related in the meta data stored in the file. If I copy the file to a smb-share, dolphin does no longer show this time stamp. Surprisingly the time stamp appears again, if the file is copied again to the ext3 drive under a different name.

In order to check the meta data I also uploaded the file: dscn0021.jpg.

Opening the file in Gwenview here displays a wealth of information.
A screenshot of a small selection of it: http://simplest-image-hosting.net/png-0-r29905

It would seem this data is indeed included in the file data (both EXIF and IPTC data was present - EXIF being most detailed).

Of course the file contains meta data. But neither the EXIF nor IPTC data contain this pathological time stamp. I have hundreds of images where dolphin show this special time stamp while the EXIF and IPTC data seem to be correct.

@bcooksley: Have you found this special time stamp somewhere in the meta data?

I'd really like to fix this in either the file system or the files themselves. Otherwise searching nepomuk by date is not practical.

I have two "Date & Time" fields shown in the image information section of Gwenview. One marked "original" and the other "digitized".

Both of these are dates in 2005 however. The file creation time shown with both Nepomuk enabled or disabled is 949736461 (which is a date in 2000 it seems).

I certainly do not see any date in the 2100's.

So it seems that this is a bug in dolphin/nepomuk (or one of the underlying libs).

The image metadata extraction is handled by Strigi. Please file a bug at bugs.kde.org against Dolphin however, so this can be confirmed by the developers.