Re: [Tracker] ... elements/1.1/date question. FAT16 bug!

[Alexey Fisher <bug-track fisher-privat net>]

Am Freitag, den 26.03.2010, 19:31 +0200 schrieb Alexey Fisher:
> Hallo all,
>
> i checking the filedates tracker provide and found some thing i can't
> understand. For example:
>
> ~$ tracker-info P1070214.MOV | grep date
>   'http://purl.org/dc/elements/1.1/date' = '2010-03-04T22:00:00Z'
>   'http://purl.org/dc/elements/1.1/date' = '2010-03-05T07:06:06Z'
>
> second is creation time in UTS. what is first date?
> More info:
>
> ~$ stat P1070214.MOV 
>   File: âP1070214.MOVâ
> Access: 2010-03-26 00:00:00.000000000 +0200
> Modify: 2010-03-05 09:06:06.000000000 +0200
> Change: 2010-03-05 09:43:51.000000000 +0200
>
> ~$ exiftool P1070214.MOV | grep -i date
> File Modification Date/Time     : 2010:03:05 09:06:06+02:00
> Create Date                     : 2010:03:05 09:06:07
> Modify Date                     : 2010:03:05 09:06:07
> Track Create Date               : 2010:03:05 09:06:07
> Track Modify Date               : 2010:03:05 09:06:07
> Media Create Date               : 2010:03:05 09:06:07
> Media Modify Date               : 2010:03:05 09:06:07
>
> As you can see, nothing is telling about 2010-03-04T22:00:00Z

Update:
This is FAT16 issue. You use access time, but on FAT16 it is not
complete. I checked it with different files and cameras. As you can see:

Access: 2010-03-26 00:00:00.000000000 +0200
Modify: 2010-03-26 11:31:04.000000000 +0200
Change: 2010-03-26 11:31:04.000000000 +0200

Access has only year-month and day not time.

Is it possible to avoid getting access time from FAT16 storage?

Regards,
Alexey