[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SD card, exfat, file mtime wrong



On Mon 06 Dec 2021 at 18:37:37 (-0800), David Christensen wrote:

> I recently installed debian-live-11.1.0-amd64-xfce+nonfree.iso on a
> Dell Latitude E6520:
> 
> 2021-12-06 17:52:45 dpchrist@laalaa ~
> $ cat /etc/debian_version ; uname -a
> 11.1
> Linux laalaa 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30)
> x86_64 GNU/Linux
> 
> I am in California, USA.  My timezone is Pacific Standard Time (PST).
> UTC is 8 hours ahead.  tzselect(1) calls my timezone
> "America/Los_Angeles".
> 
> When I insert a SDXC card formatted with exfat into a USB adapter,
> plug the adapter into the laptop, and double-click on the icon that
> appears on the desktop, the SD card filesystem is mounted:
> 
> 2021-12-06 17:52:53 dpchrist@laalaa ~
> $ mount | grep media
> /dev/sdc1 on /media/dpchrist/**redacted** type exfat (rw,nosuid,nodev,relatime,uid=**redacted**,gid=**redacted**,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro,uhelper=udisks2)
> 
> When I list the files on the SD card, the mtime is wrong.  For
> example, here is a photograph that I took about ten minutes ago:
> 
> 2021-12-06 18:13:02 dpchrist@laalaa
> /media/dpchrist/**redacted**/DCIM/**redacted**
> $ ll IMG_6947.JPG
> -rwxr-xr-x 1 dpchrist dpchrist 3988022 2021-12-06 10:02:57 IMG_6947.JPG
> 
> It appears that mount(8) and/or the exfat driver consider the mtime to
> be in UTC, and are applying my timezone adjustment of -08:00 hours
> (?).
> 
> I would like Debian 11 to display the mtime without any modification
> (e.g. correct local time).
> 
> Suggestions?

I would first start with the camera. What do the internal timestamps
say about when you took the photograph. (I find it useful to take a
photograph of a clock, and archive it.) Then look at the filesystem
timestamp (which you've done). And of course, there's the filename,
sometimes a sequence number, sometimes a timedate (mangled, so it
usually sorts in a bizarre order). They're all different.

The camera in my mobile telephone writes precise UTC timestamps in
the file. I never see the filesystem as I can only bluetooth them out.
However, the filenames are local minute-accurate timestamps.

A SIM-less mobile (same manufacturer, different brand) behaves
entirely differently, using local time for both. That mobile /must/
display local time as it's my bedside/alarm clock. (It's odd: the
time is not precise, yet it knows when to switch from standard
to DST. I haven't worked out how it does that.)

I keep the clock in my real camera set to UTC at all times, avoiding
any problems (when mounted with options below). But you'd never
want to routinely tell the time by working through its menus.

Next comes the filesystem, exFAT, which I've not yet had to use.
The wiki page says it uses local time, but has a time zone marker
in offset relative to UTC (starting with Vista SP2). So that means
there are probably newer devices out there that write it, and older
ones which don't. So you'd need to check the behaviour writing onto
both FAT and exFAT filesystems. And really you need to repeat your
check in winter/summer. Does your device know the real local time
or is it just counting time since you last set it. (Trust microsoft
to screw things up yet again.)

Finally, what does linux do, and are there mount options for exFAT.
My SD cards are always mounted with:
vfat rw,errors=remount-ro,utf8,tz=UTC,shortname=mixed,user,noauto,fmask=137,dmask=027
regardless of which camera it was used in. When I copy the files
off the card to a "proper" filesystem, I run a program that
observes the camera's fingerprint, and makes appropriate adjustments
to the filenames, and both internal and filesystem timestamps.
(Eg, two of our phones add a/b/… suffixes to pictures taken within
the same minute, yet the seconds can be read from the internal
timestamps even if the timezone is wrong.)

Whether there's another adjustment for people running RTC=local,
I have no idea. Ditto for anyone who lets Windows loose on the task.

Cheers,
David.


Reply to: