Correctly handle lockfiles without writes

[alexlarsson]

A newly created lock-file is of size zero, which happens for example if you reset the storage state. In this state, lockfile.Modified() always returns true, because it thinks any short read means something changed.

I ran into this with the image store, which was empty (using images from a different store), and it keept re-reading the image store all the time even if nothing changed (i.e. both lock file reads returned zero bytes).

The proper way to handle this seems to be to compare partial reads also.

Signed-off-by: Alexander Larsson alexl@redhat.com

[giuseppe]

LGTM

[rhatdan]

LGTM

[mtrmac]

This does look like an improvement, but I can’t see that this is quite correct: createLockerForPath creates an object with a new random lw value that matches nothing, so the first use of a lock is always going to return Modified() == true.

So, callers like layerStore are, AFAICS going to load the state in every case (because they are hard-coded to do so on creation), and then re-read it on the first actual use (via ReloadIfChanged→Modified).

Without examining all of the codebase in detail I’m not comfortable with just changing this behavior of Modified — but longer term, ultimately, it seems to me that the right model is to read the lw value from the lock before reading the data (= manually inspect all users), and having Modified return false on the first call.

[nalind]

This appears to be causing test failures at containers/podman#16211.