On 2024-06-19, J.F <j...@p...onet.pl> wrote:
> 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ą.

Nawet nie mają na pokładzie GPSa (wiekszość modeli), więc z założenia
jakby mniej.

> 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?

Np. cp -a, albo pod midnigh commanderem.

> 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 jest z pliku, który nie jest na karcie, ale jest na dysku pod zfs'em.
Nie potrafię powiedziec, dlaczego akurat 17 dni przed access ale mogłem
ten plik np. linkować z katalogu wyżej, bo mam taki system
dostępu/przechowywania na dysku. Zresztą wiąże się posrednio z tą
dyskusją - orygianlne pliki są w jakis podkatalogach, a z katalogu
głowniejszego idą do nich linki o nazwach zawierających "time stamp",
tak że sortowanie po nazwię ustawia je w porządku chronologiczmym/

>> 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.

Pewnie tak. Aż tak bardzo się nie wgłębiałem.

>> # 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.

Może windows czyta coś z jakiegoś innego pola? Czyim wynalzkiem jest
exFAT?
https://en.wikipedia.org/wiki/ExFAT
"exFAT (Extensible File Allocation Table) is a file system
introduced by Microsoft in 2006"

Ta firma jest dobrze znana z robienia czegoś bez ujawniania pełnej
specyfikacji (po nieudokumentowanych funkcjach). Jesli przy p kazji i z
tym coś spieprzyli, to też nie dziwi.

>> 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ł.

Trochę dziwne, ale nie niemożliwe.

--
Marcin