0

Just encountered a problem: when rebooting a Linux system, timestamps of all files in mounted vfat filesystem are shown in the incorrect timezone. It seems like a device starts thinking that its local time is in UTC, so it displays all timestamps with the shift.

Steps to reproduce:

  • Create some small FAT-formatted image:

    dd if=/dev/zero of=small.img bs=1M seek=1 count=0

    mkfs.vfat small.img

  • Mount this image locally:

    mount -t vfat -o umask=0022,gid=1001,uid=1001 small.img mnt

  • Set the timezone to some non-UTC one;

  • Create a file in the mounted filesystem (ie. touch mnt/newfile)

  • Observe the file modification/change timestamps: they are correct, in relation to the currently set one:

    stat mnt/newfile

    File: mnt/newfile
Size: 0             Blocks: 0          IO Block: 16384  regular empty file
Device: 700h/1792d  Inode: 40          Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-03-22 12:19:56.000000000 +0100
Modify: 2021-03-22 12:19:56.000000000 +0100
Change: 2021-03-22 12:19:56.000000000 +0100
Birth: -

    timedatectl

    Local time: Mon 2021-03-22 12:19:07 CET
Universal time: Mon 2021-03-22 11:19:07 UTC
RTC time: Mon 2021-03-22 11:19:07
Time zone: Europe/Vienna (CET, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

  • Unmount the filesystem, to check if anything has been changed with the remount: umount mnt; mount -t vfat -o umask=0022,gid=1001,uid=1001 small.img mnt; stat mnt/newfile

    File: mnt/newfile
Size: 0          Blocks: 0          IO Block: 16384  regular empty file
Device: 700h/1792d   Inode: 64          Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-03-22 00:00:00.000000000 +0100
Modify: 2021-03-22 12:19:56.000000000 +0100
Change: 2021-03-22 12:19:56.000000000 +0100
Birth: -

  • Reboot the system;

  • Mount the image once more, have a look at the created file's timestamps:

    File: mnt/newfile
Size: 0             Blocks: 0          IO Block: 16384  regular empty file
Device: 700h/1792d  Inode: 26          Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-03-22 01:00:00.000000000 +0100
Modify: 2021-03-22 13:19:56.000000000 +0100
Change: 2021-03-22 13:19:56.000000000 +0100
Birth: -

It can be clearly observable, that the time is shifted forward by 1 hour (12:10 to 13:19), while the timezone is shown the same - +0100. Looks like mount now thinks that the file timestamps were recorded in UTC, so it tries to display them with the "correct" shift.

To check the validity of the previous statement, let's remount the same filesystem with the tz=UTC option explicitly:

mount -t vfat -o umask=0022,gid=1001,uid=1001,tz=UTC small.img mnt; stat mnt/newfile

File: mnt/newfile
Size: 0          Blocks: 0          IO Block: 16384  regular empty file
Device: 700h/1792d   Inode: 50          Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-03-22 01:00:00.000000000 +0100
Modify: 2021-03-22 13:19:56.000000000 +0100
Change: 2021-03-22 13:19:56.000000000 +0100
Birth: -

Even though the system's timezone is CET indeed:

date

Mon Mar 22 12:26:42 CET 2021
vmlinuz
  • 11
  • 4
  • 1
    [so] is for programming questions, not questions about using or configuring Unix and its utilities. [unix.se] or [su] would be better places for questions like this. – Barmar Mar 22 '21 at 15:39
  • Agreed that it belongs elsewhere, but see the answer to the question I linked as duplicate - it explains why you are getting these results. – Matt Johnson-Pint Mar 22 '21 at 16:06
  • @MattJohnson-Pint Thanks for such a timely comment! Sorry, but why is this change seen right after reboot the machine and not after a remount? If vfat stores timestamps in local time, why does `mount` after rebooting assumes that the timestamps are in UTC rather than local time? – vmlinuz Mar 22 '21 at 16:21
  • I'm not sure. You should ask that on one of the other two sites Barmar linked to. StackOverflow is for programming questions. Thanks. – Matt Johnson-Pint Mar 22 '21 at 17:13

0 Answers0