🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.rec.foto.cyfrowa
Article #912747

Re: czas exif a czas modyfikacji pliku

#912747
From: J.F
Date: Wed, 19 Jun 2024 17:32
163 lines
7769 bytes
On Wed, 19 Jun 2024 01:21:51 GMT, Marcin Debowski wrote:
> On 2024-06-18, J.F <jfox_xnospamx@poczta.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-time-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/fileio/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.
Technical Details
Message-ID: <6aqxnmklndyt$.1w6zvf4fr4g35.dlg@40tude.net>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!news.chmurka.net!.POSTED.157.25.139.242!not-for-mail
References: <877bO.6$SLx.3@fx04.ams1> <qgoi7xi12tz4.1hx9c6nnr8x2i.dlg@40tude.net> <jR4cO.299$Bf2e.215@fx14.ams1> <bsnr343l09bo.11xtd7nptr1mj$.dlg@40tude.net> <PoqcO.20378$uZFb.18088@fx09.ams1>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!news.chmurka.net!.POSTED.157.25.139.242!not-for-mail
From: "J.F" <jfox_xnospamx@poczta.onet.pl>
Newsgroups: pl.rec.foto.cyfrowa
Subject: Re: czas exif a czas modyfikacji pliku
Date: Wed, 19 Jun 2024 19:32:44 +0200
Organization: news.chmurka.net
Message-ID: <6aqxnmklndyt$.1w6zvf4fr4g35.dlg@40tude.net>
References: <877bO.6$SLx.3@fx04.ams1> <qgoi7xi12tz4.1hx9c6nnr8x2i.dlg@40tude.net> <jR4cO.299$Bf2e.215@fx14.ams1> <bsnr343l09bo.11xtd7nptr1mj$.dlg@40tude.net> <PoqcO.20378$uZFb.18088@fx09.ams1>
MIME-Version: 1.0
Injection-Info: news.chmurka.net; posting-account="jfoxwr"; posting-host="157.25.139.242"; logging-data="6076"; mail-complaints-to="abuse-news.(at).chmurka.net"
User-Agent: 40tude_Dialog/2.0.15.1
Cancel-Lock: sha1:THVEuSiP0/sqpFaCLQQu6RmYoYI= sha256:K/FPmuAeKJf12rVVRneZR2/Od68LgCeuSulXyuNv++8= sha1:hLsX6fzMPMerSt1y0QiUEClYKEg= sha256:dz3iGKDaKBP5THB6KxS1Nl0522E4ieFfBy5hZPKY3Gc=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit