Has anyone else encountered this?
We just went on DST. (grrrrrrrrrr)
All my Linux servers seem to have made the change well.
Except: the time stamps on one server’s USB-mounted 8TB NTFS drive have stayed an hour behind. That volume is the destination for several duplicati backups.
Naturally this is effing up rclone jobs that use it as a source - I am getting hundreds of “Updating modification time.”
Then please do the other requested test – write something yourself in the same way Duplicati would.
Also still wondering what rclone actually said and why. You could look more directly using ls or stat.
I would have to be able to write before the time change and check it after so this opportunity only presents itself twice a year.
Some responses I saw about this on Stack Exchange suggest this is possibly a quirk of FAT-based file systems on Linux. My plan before the next time change (gotta love a long deadline, huh?) is to rebuild this one as xfs.
I misunderstood that you had an ongoing problem with things like rclone. This was a one-time nuisance?
You said it was NTFS. If this is FAT and the others NTFS, that makes FAT even more of a suspect. NTFS keeps times in UTC and converts for use, based on local time rules. FAT keeps time stamp as local time.
File Times and Daylight Saving Time from Microsoft makes me think FAT can also get weird on Windows.
It’s been awhile since my hard drive was on FAT. I forget what it did. Anyway, good luck next DST change.