File Timestamps Change by 6hours on File Copy

[SamirD]

I've seen this happen for better part of a decade now (at least since 2015) and am really curious as to the root cause explanation because I can't think of a single reason in theory that it should be happening.

The scenario is 2x FAT32 drives connected to 2x xp computers at the end of an IPsec tunnel. Copy a file from one end to the other and the timestamps look the same from the source computer. Physically take the source drive and connect it to the destination computer and compare the file with the destination drive and the timestamp is off exactly 6 hours. Same timezone on both computers, so no funny business there. Same dst settings on both systems, so can't be that either. Makes no sense since both systems are basically twins and the drives are nothing special either.

What else can cause the time to shift like this? I've seen it happen over a couple of different IPsec tunnels being used as the source and it just bugs me. The files compare properly so there's nothing different between the source and destination file other than that 6hrs difference in the timestamp.

Any ideas welcome. This one just puzzles me. Hoping someone has seen this and recognizes it.

 

[auntjemima]

My guess would be the drive being connected as a data drive in the PC is registering time different than an OS drive. Probably reverting to UTC.

 

[kydsid]

My guess would be the drive being connected as a data drive in the PC is registering time different than an OS drive. Probably reverting to UTC.

My guess too. Op you in the US central time zone, 6 off of UTC?

 

[Nobu]

The timestamp should be "this many ticks after epoc," so if you are seeing a difference from one machine to the other, it's either that the time is set differently on one of the machines, or it's set the same but it's reporting a different time to your tunnel (or the computer accessing the device through the tunnel).

 

[Nobu]

Or, if your ipsec tunnel's server reports it's time as well, and that is incorrect, then that could cause the clients to translate timestamps wrong...maybe?

 

[SamirD]

My guess would be the drive being connected as a data drive in the PC is registering time different than an OS drive. Probably reverting to UTC.

This is typically only applicable to NTFS since FAT32 only remembers the DST bit, but otherwise just writes the timestamp like the old DOS days which didn't care about the time zone.

 

[SamirD]

My guess too. Op you in the US central time zone, 6 off of UTC?

Hmmm...it is central time. But this shouldn't be the case since files written locally have the right time stamp...wait a second--I need to confirm that those destination systems also have their time zone set to central, which I thought they did. This could be the issue for sure. Thank you for the idea!

 

[SamirD]

Just confirmed destination systems are also set to central time zone.

Any other ideas?

 

[SamirD]

Still going on. So stupid that I have to carry a drive to copy the files locally to copy them to the server on the other side with the right time stamps--there's a freaking ipsec VPN tunnel between the sites but these timestamps end up wrong.

One strangeness I just saw and need to confirm when I have boots on the ground on the other side is that even if I'm rdping into a system on the other side and looking at the file store from the local side, the timestamps are still off--now this doesn't make sense as it's all local and it's just sending me the screen updates via rdp...

 

[SamirD]

One thing that might have been a factor is the time zone on a particular machine where files were generated--it was set to gmt vs cst. I've changed it so let's see what happens.

 

[Nobu]

One thing that might have been a factor is the time zone on a particular machine where files were generated--it was set go gmt vs cst. I've changed it so let's see what happens.

Don't forget to check/update the time in the OS as well. ntpd (or whatever the daemon is) on linux doesn't update the OS time if it's off by too much, not sure about windows.

 

[SamirD]

Don't forget to check/update the time in the OS as well. ntpd (or whatever the daemon is) on linux doesn't update the OS time if it's off by too much, not sure about windows.

Yep, this is in the OS. Windows does the same, which imo is stupid. If I wanted to set the time manually, then I would just do that instead.