# Weird filesystem timestamps behavior on Linux/ARM64 workers

**URL:** https://travis-ci.community/t/weird-filesystem-timestamps-behavior-on-linux-arm64-workers/10053
**Category:** Multi CPU Architecture
**Created:** [October 1, 2020, 4:25am UTC](https://travis-ci.community/t/weird-filesystem-timestamps-behavior-on-linux-arm64-workers/10053 "2020-10-01T04:25:01Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![jkowalski](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/jkowalski/32/4102_2.png) [@jkowalski](https://travis-ci.community/u/jkowalski)
#### Post date: [October 1, 2020, 4:25am UTC](https://travis-ci.community/t/weird-filesystem-timestamps-behavior-on-linux-arm64-workers/10053/1 "2020-10-01T04:25:01Z")

</div>

I’ve noticed really weird behavior of filesystem timestamps on some (but not all) ARM 64 workers.

It appears that on some workers, the filesystem is not preserving precise modification times when I do `chtimes()` (this is using Golang but should not matter much).

For example, [https://travis-ci.org/github/kopia/kopia/jobs/729627981](https://travis-ci.org/github/kopia/kopia/jobs/729627981) logs:

```
filesystem_storage.go:254: [repo/filesystem] updating timestamp on /tmp/r-fs988822604/392/ee1/bc299db9f235e046a62625afb84902.f to 2020-09-23 14:03:22.925347001 +0000 UTC m=+6.534671441

```

but later the timestamp comes back as:

2020-09-23 14:03:22 +0000 UTC

Interestingly enough files are initially created with precise timestamps (including sub-second units), but it appears that chtimes() is causing precision loss.

As I mentioned, this is not consistent behavior, on most runs, the filesystem behaves correctly.

Recent example that did not have this problem: [https://travis-ci.org/github/kopia/kopia/jobs/731793004](https://travis-ci.org/github/kopia/kopia/jobs/731793004)

Is there some variability in filesystem type in the underlying workers that causes this?