Canonowi pewnie o nic nie chodzi, za to Twojemu programowi w kompie zapewne o coś
chodzi.
U mnie inaczej wygląda posortowanie po dacie plików w Win Explorerze, a inaczej w TC.


-----
> Ja to wiem, ale nie rozumiem o co chodzi Canonowi.

do góry

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.

do góry

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

do góry

Problem jest szerszy.
Np. PC z Win widzi zdjęcia w aparacie/smartfonie podłączonym kabelkiem USB jako
podkatalogi, a nie jako pliki graficzne.
Podkatalogi ze zdjęciami inaczej się nazywają, gdy podglądasz z korpusu Sony
kabelkiem, a inaczej gdy przepinasz z aparatu kartę
pamięci ze zdjęciami do czytnika kart w PC.
Aparat przez PC z Win w ogóle nie jest widziany jako urządzenie USB z literą"dysku"
które możesz np. "odpiąć", lecz musisz gmerać w
"This PC" -> Sony .....
Te uwagi jeszcze bardziej do telefonu podpiętego kabelkiem.
Np. w IrfanView Thumbnails nie podejrzę całego katalogu ze zdjęciami na podpiętym
kabelkiem USB smartfonie Sony, bo jak wyżej każde
zdjęcie to osobny podkatalog zamiast po prostu pliku (BARDZO mi to utrudnia szybkie
przeglądanie na kompie zdjęć z fona bez ich
uprzedniego zgrywania).
Lata temu na forach fotograficznych ostrzegano, że karty SD Sony mogą źle
funkcjonować w aparatach innych marek (jakiś niuans
formatowania).


-----
> 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.
> Trochę dziwne, ale nie niemożliwe.

do góry