You are not logged in.

#1 2014-08-30 16:08:01

imrehg
Member
From: London, UK
Registered: 2008-04-10
Posts: 108
Website

Files creation time on digital camera's SD is now offset with timezone

Been checking out the photos I've took with a digital camera by taking the SD card and mounting it in current (all up to date) Arch. It was weird to see that the latest photos are shown as being in the future. Basically the camera don't know about time zones, and creates files at the date/time I set (based on local time). On the other hand, Arch suddenly interprets that date/time as UTC while I'm actually in UTC+8 - so all the photos appear 8 hours in the future compared to when they were actually taken.

This is caused by some new change, though not sure how recently. I still have pictures on my SD card from April that I can compare to their copies made on the hard drive. The files on my hard drive (copied from the same card in April) have correct time (are in localtime). Same ones on the SD card are now 8 hours off when I mount now and check them....

Here's an example, highlighted one of the file on the SD card (left) and on the hard drive copied a few months ago (right). Same file, different interpreted time.
http://i.imgur.com/XvhVrYT.png
Similarly for all the subsequent files in the directory as well.

This is very strange to me, what setting or software can cause such a time error?

-- mod edit: replaced img with url, please see image guidelines and post thumbnails only.  Trilby --

Last edited by Trilby (2014-10-12 14:09:45)

Offline

#2 2014-08-30 16:30:45

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: Files creation time on digital camera's SD is now offset with timezone

It's a change in systemd-216, from the changelog:

        * systemd will no longer inform the kernel about the current
          timezone, as this is necessarily incorrect and racy as the
          kernel has no understanding of DST and similar
          concepts. This hence means FAT timestamps will be always
          considered UTC, similar to what Android is already
          doing. Also, when the RTC is configured to the local time
          (rather than UTC) systemd will never synchronize back to it,
          as this might confuse Windows at a later boot.

There is a time_offset mount option for vfat filesystems, it takes minutes as argument, so for an 8 hour difference, you'll need to mount the SD card with time_offset=480

Offline

#3 2014-10-12 14:07:07

lxyd
Member
Registered: 2014-10-12
Posts: 4

Re: Files creation time on digital camera's SD is now offset with timezone

Hello, imrehg!
I solved this issue by creating mount.vfat helper that calculates current timezone offset:

#!/usr/bin/env bash
mount -itvfat -oiocharset=utf8,time_offset=$((`date +%:z|sed -r 's/^(.)0?(.*):0?/\1\2*60\1/'`)) "$@"

It might help you too.

UPD: I forgot to mention: this script must be saved as executable /usr/bin/mount.vfat

Last edited by lxyd (2014-10-12 16:21:50)

Offline

#4 2014-10-12 15:10:22

imrehg
Member
From: London, UK
Registered: 2008-04-10
Posts: 108
Website

Re: Files creation time on digital camera's SD is now offset with timezone

Thanks a lot, that's neat! I wonder if there's a way to do this automatically with system settings (i.e. when using the graphical interface to mount FAT drives), and not just mount things manually, something like udev rules... I was trying to do something like

ENV{ID_FS_USAGE}=="vfat", ENV{UDISKS_MOUNT_OPTIONS}="iocharset=utf8,time_offset=480"

or

ACTION=="add", ENV{ID_FS_TYPE}=="vfat", ENV{mount_options}="$env{mount_options},time_offset=480"

in an udev rule (of course my hardcoded 480 could later potentially be scripted in the rules). The problem is that I seem to get an empty ID_FS_TYPE with the SD card that I try to mount. From the wiki, the testing code should be

udevadm test $(udevadm info -q path -n <devicepath>) 2>&1 |grep ID_FS_TYPE

where I got to fill out the devicepath. The result is

.ID_FS_TYPE_NEW=
ID_FS_TYPE=

and thus the rule fail... As I look into how mounting is done in systemd, there are just so many redirections... Whether I can adjust the mount options directly, or got to talk to udisk/udisk2, or even where the default mount options are coming from is quite confusing for me at the moment.... But on this path I think there's a more practical and more lasting.

Offline

#5 2014-10-12 16:03:44

lxyd
Member
Registered: 2014-10-12
Posts: 4

Re: Files creation time on digital camera's SD is now offset with timezone

In my experience mount.vfat helper works well with Cinnamon's automount, so I thought it would work with any GUI etc.

Offline

#6 2014-10-13 07:11:00

imrehg
Member
From: London, UK
Registered: 2008-04-10
Posts: 108
Website

Re: Files creation time on digital camera's SD is now offset with timezone

Hah, that edit makes sense in your last post, I thought it's a manual mount script, haven't used mount helpers before. smile

Tried it and works pretty neat, thanks! I feel that there's an alternative udev solution as well that appends to the mount options, instead of redefine them (like in the helper's case), but that's for some other time. This makes me a happy camper again, thanks a lot!

Offline

#7 2014-10-13 11:31:49

lxyd
Member
Registered: 2014-10-12
Posts: 4

Re: Files creation time on digital camera's SD is now offset with timezone

So it's finally working. That's cool! smile

imrehg wrote:

I feel that there's an alternative udev solution as well…

If you manage to find this udev solution one day, please share it in this topic. I would be glad to try it out too.

Offline

#8 2014-10-16 10:18:56

lxyd
Member
Registered: 2014-10-12
Posts: 4

Re: Files creation time on digital camera's SD is now offset with timezone

I just couldn't stop %) Made it keep all the options provided by user, not replace them. Much more code now.

/usr/bin/mount.vfat

#!/usr/bin/env bash

OPTS=(
    "time_offset" "$((`date +%:z|sed -r 's/(.)0?(.*):0?/\1\2*60\1/'`))"
    "iocharset"   "utf8"
)

function _build_opts() {
    local RES="$1"
    local I
    local PROP
    local VAL

    for (( I=0; I<${#OPTS[@]}; I=I+2 )); do
        PROP="${OPTS[I]}"
        VAL="${OPTS[I+1]}"
        if [[ -z "$RES" ]]; then
            RES="$PROP=$VAL"
        elif [[ ! "$RES" =~ (^|^-[^tOo]*o|,)$PROP= ]]; then
            RES="$RES,$PROP=$VAL"
        fi
    done

    echo "$RES"
}

ARGS=("$@")
CNT=${#ARGS[@]}
APPEND_IDX=-1
for (( I=0; I<$CNT; I++)); do
    if [[ "${ARGS[I]}" =~ ^-[^tOo]*o.+$ ]]; then
        # bunch of options ending with -oopti=ons: -aoiocharset=utf8
        APPEND_IDX=$I
        break
    elif [[ "${ARGS[I]}" =~ ^-[^tOo]*o$ ]]; then
        # options are separated: -ao opti=ons
        APPEND_IDX=$((I+1))
        break
    elif [[ "${ARGS[I]}" =~ ^-[^tOo]*[tO]$ ]]; then
        # skip next option
        I=$((I+1))
    fi
done

if (( APPEND_IDX == -1 )); then
    ARGS[$CNT]="-o$(_build_opts)"
elif (( APPEND_IDX == CNT )); then
    # rare case: empty -o was the last option
    ARGS[$CNT]="$(_build_opts)"
else
    ARGS[$APPEND_IDX]="$(_build_opts ${ARGS[$APPEND_IDX]})"
fi

mount -itvfat "${ARGS[@]}"

Last edited by lxyd (2014-10-16 10:31:57)

Offline

Board footer

Powered by FluxBB