On Wed, 19 Jun 2024 01:21:51 GMT, Marcin Debowski wrote:
> On 2024-06-18, J.F <j...@p...onet.pl> wrote:
>> On Tue, 18 Jun 2024 00:50:23 GMT, Marcin Debowski wrote:
>>> Jeszcze mogę sprawdzić pod łindows, ale na 2ch Linuksach tak jest. 8h
>>> się zgadza tylko, że nie w tę stronę. Zdjęcie zostało zrobione o 11:22
>>> czasu lokalnego w TZ GMT+8. Mógłbym zrozumieć jakby to było 03:22, ale w
>>> drugą stronę jakoś nie widzę w tym żadnej logiki.
>>>
>>> Nb. widzę, że więcej zdjęć mam takich, nie tylko canonowskich (np. z Gopro)
>
> Sprawdziłem pod windows i robi się coraz ciekawiej, ale o tym za chwilę....
>
>>> ale np. Olympus TG5 ustawia poprawnie:
>>>
>>> Oryginalny plik:
>>> File Modification Date/Time : 2018:06:09 20:28:20+08:00
>>> File Access Date/Time : 2024:06:18 08:06:33+08:00
>>> File Inode Change Date/Time : 2024:06:01 15:11:28+08:00
>>> Modify Date : 2018:06:09 20:28:21
>>> Date/Time Original : 2018:06:09 20:28:21
>>> Create Date : 2018:06:09 20:28:21
>>> Date Time UTC : 2018:06:09 12:28:21
>>
>> A wczesniej tego UTC nie było ?
>> To nadal dane pliku, czy Exif?
>
> To jest Exif. Dla jasności, te dane to otrzymuję
> #exiftool |grep -i date
>
> Pierwsze 3 to raczej z pliku, ale dalsze z rekordu exif.

>> Czyzby TG5 zapisał UTC, a Canon nie?
>
> Na to wygląda. TG5 to jest produkt w intencji dla podróżników, więc
> podejrzewam, stąd Olympus dał tam UTC. Albo UTC przyplątał się z GPSu.

Canony pewnie też sporo podrózują.

Ale moze nikomu nie przeszkadzało :-0

>> Ale czemu tylko jeden, i nie wiadomo do czego się odnosi..
>>
>>> Create Date : 2018:06:09 20:28:21+08:00
>>> Date/Time Original : 2018:06:09 20:28:21+08:00
>>> Modify Date : 2018:06:09 20:28:21+08:00

Za tym Date/Time Original chyba stoi jakis pomysł ...

>>> Powyższy plik przekopiowany blok po bloku dziś rano:
>>
>> No chyba jednak nie tak prosto, bo zachował kilka dat oryginału.
>> Czyli to jakies ambitniejsze kopiowanie, łącznie z czasami pliku.
>
> Nie nie, chodzi o coś innego. Jak się używa programu do kopiowania
> (dedykowanego),

polecenie cp z shella?

> to ten program najczęsciej ustawia czas modyfikacji
> kopii aby był taki sam jak dla oryginału. Jak zrobię po blokach, np. dd
> if=oryginał of=kopia, to zawartość będzie taka sama ale czas modyfikacji
> utworzenia kopii.

OK, zrozumiałem.

Zastanawia mnie jednak to
Oryginalny plik:
File Modification Date/Time : 2018:06:09 20:28:20+08:00
File Access Date/Time : 2024:06:18 08:06:33+08:00
File Inode Change Date/Time : 2024:06:01 15:11:28+08:00

Co to była za zmiana inode 1.06?
I czy na karcie są w ogóle jakies inode ?

>>>> To plik na karcie? W jakim formacie?
>>>
>>> vfat lub exfat, musiałbym sprawdzić.
>>
>> czy vfat w ogóle zapamiętuje strefę czasową? Mam wątpliwości.
>> A Exfat?
>>
>> https://stackoverflow.com/questions/38549583/what-ti
me-zone-does-a-fat32-sd-card-record-timestamps-in
>> Jeśli nie jest zapamiętana, to jest wina twojego linuxa jak prezentuje
>> daty plików :-)
>
> I co, wymyslił sobie, żeby dodać 2x po 8h? :)

Trudno powiedzieć, co sobie wymyślił, ale chyba coś powinien.

>> ExFat zapamiętuje "UtcOffset":
>> https://learn.microsoft.com/en-us/windows/win32/file
io/exfat-specification
>>
>> Czy twój system dobrze to pokazuje to nie wiem.
>> A czy aparat dobrze zapisuje, to tez nie wiem :-)
>
> Dobra, to teraz tak, FS poniżej to jest exFAT. Sprawdziłem pod Windows i
> Linuksem. Dla uproszczenia tylko 2 pliki:
>
> Win:
> 14/06/2024 07:59 PM 10,117,418 IMG_0050.JPG
> 14/06/2024 12:14 PM 8,234,827 IMG_0051.JPG
>
> Lin:
> -rw-rw---- 1 agatek agatek 10117418 Jun 14 19:59 IMG_0050.JPG
> -rw-rw---- 1 agatek agatek 8234827 Jun 14 20:14 IMG_0051.JPG

Hm, 7:59PM to 19:59, ale przecież 12:14 PM to nie 20:14 ...

Plik pod windows moze ma wiecej dat, ale to chyba dopiero Powershell
Ci powie.

> # exiftool IMG_0050.JPG|grep -i date
> File Modification Date/Time : 2024:06:14 19:59:41+08:00
> File Access Date/Time : 2024:06:14 12:11:14+08:00
> File Inode Change Date/Time : 2024:06:14 19:59:41+08:00
> Modify Date : 2024:06:14 11:59:39
> Date/Time Original : 2024:06:14 11:59:39
> Create Date : 2024:06:14 11:59:39
> Create Date : 2024:06:14 11:59:39.99+08:00
> Date/Time Original : 2024:06:14 11:59:39.99+08:00
> Modify Date : 2024:06:14 11:59:39.99+08:00
>
> # exiftool IMG_0051.JPG|grep -i date
> File Modification Date/Time : 2024:06:14 20:14:17+08:00
> File Access Date/Time : 2024:06:19 07:40:40+08:00
> File Inode Change Date/Time : 2024:06:14 20:14:17+08:00
> Modify Date : 2024:06:14 12:14:16
> Date/Time Original : 2024:06:14 12:14:16
> Create Date : 2024:06:14 12:14:16
> Create Date : 2024:06:14 12:14:16.46+08:00
> Date/Time Original : 2024:06:14 12:14:16.46+08:00
> Modify Date : 2024:06:14 12:14:16.46+08:00
>
> Tak, że nie wiem co tam widzi mój Linuks, ale to co widzi Windows to, że
> te dwa zdjęcia zostały zrobione w odstępie 4h gdy w rzeczywistości było
> to 14 min.
>
> Skąd różnica pomiędzy plikiem "50" a "51", nie wiem ale mam pewne
> podejrzenia: Canon uzywa orpogramowania synchronizującego/tagującego,
> canon connect, które działa pod Androidem. Być może 51 jest po
> połączeniu z tym oprogramowaniem.

no ale na karcie masz zapisane to co masz zapisane, linux pokazuje
dobrze, a windows pokazuje źle. I tyle.

Podejrzewam, że mają jakiś błąd w programie przeliczającym,
być moze powiązany z datą.
Jakby tak np o tej 19:59 był jeden dzien, a o 20:14 juz następna data,
ale to tak trochę nie pasuje to tej strefy +0800


> Z tym, że jakby to nie tłumaczy
> problemu GMT+16, skoro i w aparacie i w androidzie i pod windows i pod
> linuksem, są wszędzie poprawnie ustawione strefy czasowe.
>
> Generalnie, jak już ącki zauwazył, są programy, które ustawiają ctime
> pliku podług exif. Tych programów jest sporo.

No ale musiałbys go uruchomić. Pod linuxem sam się nie uruchomi,
ale czy Windows nie ma takiego wbudowanego, i czy nie zadziała np przy
wejsciu do katalogu w explorerze, to już bym się nie założył.

J.