Timestamps off by 1 or 2 months in the future

renordw · 2020-04-10 04:55:58

To be honest, I am not even sure how to begin troubleshooting this issue. I frequently run into a problem where my timestamps are off by exactly 1 or 2 months in the future. For instance, here is a directory:

$ls -alh
-rwxr-xr-x  1 ryandward ryandward  70M Apr  5 02:23  .Library_S1_L001_R1_001.fastq.gz.SxcYsp
-rwxr-xr-x  1 ryandward ryandward   83 Apr 26  2020 '.~lock.COVID-19 Cases.csv#'
drwxr-xr-x  3 ryandward ryandward 128K May  9  2020  Orthos
drwxr-xr-x  5 ryandward ryandward 128K May  9  2020  RecipBlast
drwxr-xr-x  3 ryandward ryandward 128K Apr  5 02:34  Wolbachia
drwxr-xr-x  4 ryandward ryandward 128K Apr 13  2020  Zymo

Clearly, it is not May 9th 2020 yet. I also deleted some files earlier that were June 9 2020.

jasonwryan · 2020-04-10 05:07:39

timedatectl

renordw · 2020-04-10 05:08:44

$ timedatectl
               Local time: Fri 2020-04-10 00:08:12 CDT 
           Universal time: Fri 2020-04-10 05:08:12 UTC 
                 RTC time: Fri 2020-04-10 05:08:12     
                Time zone: America/Chicago (CDT, -0500)
System clock synchronized: yes                         
              NTP service: active                      
          RTC in local TZ: no

Which is all correct for my time zone

Last edited by renordw (2020-04-10 05:09:19)

jasonwryan · 2020-04-10 05:14:09

What filesystem is this? Are those files you have created, or are they copied/synced from another machine?

renordw · 2020-04-10 05:16:42

I am using btrfs (main hard drive), and the files in question are generated on my machine. There doesn't seem to be an obvious pattern, sometimes BLAST output files are 1 month ahead, sometimes 2 months. Sometimes mkdir does it too.

These particular files were generated on an exfat USB drive.

Last edited by renordw (2020-04-10 05:25:55)

jasonwryan · 2020-04-10 05:44:26

Can you test:

date > testfile && cat testfile && stat testfile

renordw · 2020-04-10 14:16:41

$ date > testfile && cat testfile && stat testfile
Fri 10 Apr 2020 09:15:53 AM CDT
  File: testfile
  Size: 32        	Blocks: 256        IO Block: 131072 regular file
Device: 801h/2049d	Inode: 54634       Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/ryandward)   Gid: ( 1000/ryandward)
Access: 2020-04-10 09:15:53.000000000 -0500
Modify: 2020-04-10 09:15:53.000000000 -0500
Change: 2020-04-10 09:15:53.000000000 -0500
 Birth: -

$ cat testfile
Fri 10 Apr 2020 09:15:53 AM CDT

Last edited by renordw (2020-04-10 14:17:27)

Trilby · 2020-04-10 14:21:12

I'm not sure if this would be related, by why are all files executable, and the newly created filed defaulted to 0755?

seth · 2020-04-10 14:55:04

These particular files were generated on an exfat USB drive.

renordw · 2020-04-10 19:17:23

seth wrote:

These particular files were generated on an exfat USB drive.

But the USB drive lives in my Linux box, and doesn't ever leave.

Trilby · 2020-04-10 19:23:59

*headdesk*

I missed the edit. That's why you were asked about the filesystem. The filesystem at least answers the question about everything having executable permissions. I don't know how FAT handles timestamps, so I can't help there.

But if you have a USB drive that doesn't ever leave your linux box, why on earth is it formatted as exfat?

seth · 2020-04-10 19:37:16

About the timestamps: is there actually any problem here? Have you ever perceived this with anything not related to BLAST?
Equipping a file w/ random timestamps is trivially easy ("man touch") and if BLAST downloads them from a server w/ a bad time config and maintains the timestamps, they will be off on your system as well.

renordw · 2020-04-10 20:25:08

Trilby wrote:

*headdesk*
I missed the edit. That's why you were asked about the filesystem. The filesystem at least answers the question about everything having executable permissions. I don't know how FAT handles timestamps, so I can't help there.
But if you have a USB drive that doesn't ever leave your linux box, why on earth is it formatted as exfat?

Honestly, because it just started accumulating a ton of data ~200+GB, and now I don't have a place to temporarily offload it... to reformat it. I'll reformat it whenever I get somewhere to put it.

seth wrote:

About the timestamps: is there actually any problem here? Have you ever perceived this with anything not related to BLAST?
Equipping a file w/ random timestamps is trivially easy ("man touch") and if BLAST downloads them from a server w/ a bad time config and maintains the timestamps, they will be off on your system as well.

It isn't causing huge problems, but it does have some unexpected behavior. When I sort files by newest, oftentimes something from several weeks ago looks newer (-2 real weeks + 2 fictitious months) than the files I am working on today. Moreso, a lot of scripts just hang forever until I "touch *", which causes me to lose track of what is actually the newest file.

I haven't noticed the issue occur with anything I download. It's always something that I have created myself through a variety of methods. Even mkdir *sometimes* results in a file folder a month ahead.

Last edited by renordw (2020-04-10 20:27:40)

seth · 2020-04-11 13:50:19

Even mkdir *sometimes* results in a file folder a month ahead.

Something™ deviates your system clock (and possibly the HW clock) - the process will require root permissions, so some daemon or your NTP server is bogus.

Something erroneous like

date -s month

would do this.

renordw · 2020-04-14 06:28:33

I pulled the drive off my Arch Linux box, and when I look at the dates on my Windows laptop, the two systems report the dates differently. Windows is right, Linux is 1-2 months in the future.

Actually, on Linux when I copy the files off my exfat drive onto my btrfs, the timestamps are suddenly correct.

Last edited by renordw (2020-04-14 06:39:07)

V1del · 2020-04-14 06:40:44

Output of

mount

and the relevant line for the device in question? Are you using the FUSE based exfat driver or the new in-kernel one?

renordw · 2020-04-14 06:47:19

/dev/sdb1 on /run/media/ryandward/SamsungUSB type exfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,namecase=0,errors=remount-ro,uhelper=udisks2)

I didn't install any additional drivers, it must be the in-kernel one.

Arch Linux

#1 2020-04-10 04:55:58

Timestamps off by 1 or 2 months in the future

#2 2020-04-10 05:07:39

Re: Timestamps off by 1 or 2 months in the future

#3 2020-04-10 05:08:44

Re: Timestamps off by 1 or 2 months in the future

#4 2020-04-10 05:14:09

Re: Timestamps off by 1 or 2 months in the future

#5 2020-04-10 05:16:42

Re: Timestamps off by 1 or 2 months in the future

#6 2020-04-10 05:44:26

Re: Timestamps off by 1 or 2 months in the future

#7 2020-04-10 14:16:41

Re: Timestamps off by 1 or 2 months in the future

#8 2020-04-10 14:21:12

Re: Timestamps off by 1 or 2 months in the future

#9 2020-04-10 14:55:04

Re: Timestamps off by 1 or 2 months in the future

#10 2020-04-10 19:17:23

Re: Timestamps off by 1 or 2 months in the future

#11 2020-04-10 19:23:59

Re: Timestamps off by 1 or 2 months in the future

#12 2020-04-10 19:37:16

Re: Timestamps off by 1 or 2 months in the future

#13 2020-04-10 20:25:08

Re: Timestamps off by 1 or 2 months in the future

#14 2020-04-11 13:50:19

Re: Timestamps off by 1 or 2 months in the future

#15 2020-04-14 06:28:33

Re: Timestamps off by 1 or 2 months in the future

#16 2020-04-14 06:40:44

Re: Timestamps off by 1 or 2 months in the future

#17 2020-04-14 06:47:19

Re: Timestamps off by 1 or 2 months in the future

Board footer