UFS returns changing mtime

[boosh]

BUG REPORT

minikube version: v0.18.0

Environment:

• OS: OSX Sierra 10.12.4
• VM Driver: virtualbox
• ISO version: v0.18.0
• Install tools:
• Others:

What happened:
I mounted a host directory (code/api containing server.py) into a docker container by running minikube mount $(pwd). I then declared the mount with a subpath:

    volumeMounts:
      - mountPath: /code/api
        name: local-volume
        subPath: customer/api
      - mountPath: /pems
        name: local-volume
        subPath: pems
  volumes:
  - name: local-volume
    hostPath:
      path: /mount-9p

When I use python to stat a file in /code/api it returns a constant integer part, but the fractional part keeps changing. E.g. attach to the container and run:

import os
os.stat('/code/api/server.py').st_mtime    # run this several times

Each time the second line is executed, the mtime changes, even if there are no modifications on disk. However, only the fractional part changes, e.g. I see values like:

1492534091.6000473
1492534091.2560475
1492534091.9280474

What you expected to happen:
A consistent mtime should be returned if a file hasn't been modified.

How to reproduce it (as minimally and precisely as possible):
See above.

Anything else do we need to know:
No.

[fennb]

Just confirming the above.

I am also observing exactly this behaviour. The underlying cause appears to be due to the fact that the macOS filesystem st_mtime values are only accurate to the second, and lib9p (or thereabouts) seems to "invent" the additional milli/microsecond digits (presumably the current clock value).

From a python macOS python interpreter locally:

$ python
Python 2.7.10 (default, Oct 23 2015, 19:19:21)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.stat('/etc/hosts').st_mtime
1488917238.0
>>> os.stat('/etc/hosts').st_mtime
1488917238.0

Inside a container on a 9p mounted fs:

>>> os.stat('/opt/example.txt').st_mtime
1489093407.3668966
>>> os.stat('/opt/example.txt').st_mtime
1489093407.2888966
>>> os.stat('/opt/example.txt').st_mtime
1489093407.1608965```

[aaron-prindle]

@fennb It sounds like only storing the mtime up to the second for macOS work as a solution. Does that seem reasonable?

[fennb]

@aaron-prindle It looks more like a read-time problem to me? ie: the 9p server (or client) is "making up" false precision in the absence of real data (or I may have completely misinterpreted how things actually work - I don't know lib9p at all).

Does that make sense?

[aaron-prindle]

This should be fixed now with #1594