I have a problem with the timestamps of files copied from my PC or laptop to USB drives: the last modification time of the original file and that of the copied file are different. Therefore, synchronizing files between my PC and my USB drive is quite cumbersome.

A step by step description

  1. I copy an arbitrary file from my PC/laptop to a USB drive using the GUI or with the command

    cp -a file.txt /media/gabor/CORSAIR/
    
  2. I check the last modification time of the original file:

    $ ls -l --time-style=full-iso file.txt
    -rw-rw-r-- 1 gabor gabor 0 2018-09-22 15:09:23.317098281 +0200 file.txt
    
  3. I check the last modification time of the copied file:

    $ ls -l --time-style=full-iso /media/gabor/CORSAIR/file.txt
    -rw-r--r-- 1 gabor gabor 0 2018-09-22 15:09:23.000000000 +0200 /media/gabor/CORSAIR/file.txt
    
  4. As you can see, the seconds in the last modification time of the copied file are truncated to zero decimal digits. However, if I enter the command

    if ! [ file.txt -nt /media/gabor/CORSAIR/file.txt ] && ! [ file.txt -ot /media/gabor/CORSAIR/file.txt ]; then echo "The last modification times are equal."; fi
    

I get the output The last modification times are equal.

  1. The situation changes if I unmount and remount the USB drive and I execute the last two commands again:

    $ ls -l --time-style=full-iso /media/gabor/CORSAIR/file.txt
    -rw-r--r-- 1 gabor gabor 0 2018-09-22 15:09:22.000000000 +0200 /media/gabor/CORSAIR/file.txt
    $ if [ file.txt -nt /media/gabor/CORSAIR/file.txt ]; then echo "The file is newer on the PC."; fi
    The file is newer on the PC.
    
  2. So after remount, the last modification time of the copied file is further reduced by one second. Further unmounting and remounting, however, doesn't affect the last modification time any more. Besides, the test on the files now shows that the file on the PC is newer (although it isn't).

The situation is further complicated by the fact that the last modification time of files is shown differently on my PC and on my laptop, the difference being exactly 2 hours, although the date and time setting is the same on my PC and on my laptop!

Further information

Both my PC and laptop show the behaviour, described above. I have Ubuntu 14.04.5 (trusty) on my PC and Ubuntu 16.04.2 (xenial) on my laptop.

My USB drives have vfat file system. The output of mount | grep CORSAIR on my PC is

/dev/sdb1 on /media/gabor/CORSAIR type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2)

The output of mount | grep CORSAIR on my laptop is

/dev/sdb1 on /media/gabor/CORSAIR type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

My other USB drives show the same behaviour.

Question

Can the difference in the last modification times be eliminated somehow? For example, using other parameters at mounting/unmounting? Or is it a bug in Ubuntu?

I would like to achieve that the timestamps of the original and copied files are exactly the same, so that synchronization can be done more efficiently. Also, I would like to keep the vfat file system on my USB drives, so that I can use them under Windows, too.

  • Are you willing to create another file system in the USB drive, for example a linux ext4 file system? (The support in linux for Microsoft proprietary file systems, FAT32, exFAT, NTFS, has some limits.) See this link which suggests not only ext4 but also udf as alternatives to Microsoft proprietary file systems. – sudodus Sep 23 at 12:44
up vote 16 down vote accepted

The problem with the timestamp seconds changing comes from the fact that a VFAT (yes, even FAT32) filesystem stores the modification time with only 2-second resolution.

Apparently, as long as the filesystem is mounted, the filesystem driver caches timestamps accurate to 1-second resolution (probably to satisfy POSIX requirements), but once the filesystem is unmounted, the caches are cleared and you'll see what is actually recorded on the filesystem directory.

The two-hour difference between the PC and the laptop are probably caused by different timezone settings and/or different default mount options for VFAT filesystem. (I'm guessing that you're located in a timezone whose UTC offset is currently 2 hours, either positive or negative.)

Internally, Linux uses UTC timestamps on Unix-style filesystems; but on VFAT filesystems, the (current) default is to use local time on VFAT filesystem timestamps, because that is what MS-DOS did and Windows still does. But there are two mount options that can affect this: you can specify the mount option tz=UTC to use UTC-based timestamps on VFAT filesystems, or you can use time_offset=<minutes> to explicitly specify the timezone offset to be used with this particular filesystem.

It might be that the default mount options for VFAT have changed between Ubuntu 14.04 and 16.04, either within the kernel or the udisks removable-media helper service, resulting in the two-hour difference you see.

  • Thank you for your answer. I completed my question with the output of mount | grep CORSAIR on my laptop, which is indeed different from the output on my PC. Also, you are right, I am located in central Europe in CEST (=UTC+2) time zone. – K. Gabor Sep 23 at 14:52
  • Neither of those mount outputs seem to include any mount options that would affect the timestamps, so I think the default handling for VFAT timestamps must have been changed at the kernel level somewhere between those versions of Ubuntu. Apparently modern udisks should respect mount options specified in /etc/fstab, if you write an entry for your USB drive to it. – telcoM Sep 23 at 19:13

Although I wrote in my question that "I would like to keep the vfat file system on my USB drives", finally I re-formatted them to ntfs file system. Both Linux and Windows can handle ntfs and it seems to not show the strange phenomenon with the timestamps, depicted above.

  • Yes, NTFS stores all file timestamps as 64-bit numbers based on UTC time, so they have a 100-nanosecond resolution and the date range is from 1 January 1601 to 28 May 60056. That should be more than enough. More importantly, there is no place for the kind of timezone ambiguity the VFAT filesystems have. – telcoM Oct 3 at 20:13

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.