Gregory M. Kurtzer

Great idea, and I think this should be part of the image header itself.

I like the idea of a content hash, but not sure the best model for creating one that doesn't have massive IO overhead. Thoughts?

We could also run through the container's files, and do some hashing based on what is found. While it is IO heavy, that would guarantee two containers with the same...

Oh, interesting... Pardon my lack of Pythonese, does it run recursively through all the files within image_path?

Ohhhh, this is doing a checksum of the image file itself... No, I was thinking that to do this in a reproducible manner, we need to select certain paths inside...

Well.. once the container is mounted, we could traverse recursively some key directories (perhaps, /etc, /bin, /usr, /lib*) and run these files within these paths through a checksumming algorithm, so...

That's a good point, what are our goals of the content hash? I think I'll defer to @vsoch on that one. lol

It seems to be working for me too: gmk@gmkdev2:~/git/singularity$ shasum /tmp/centos.img dc73d6a9aad0b21c1a5972d0a49b7392213934f6 /tmp/centos.img gmk@gmkdev2:~/git/singularity$ sudo singularity exec -w /tmp/centos.img sh -c "echo '' >> /singularity" gmk@gmkdev2:~/git/singularity$ shasum /tmp/centos.img 65eccc149e6f565ba85509fb35c1e0737cb7bb09 /tmp/centos.img...

Even if a single file's timestamp changes inside a container, the container itself will have an entirely different hash/checksum. And things like timestamps will indeed change from one bootstrap to...

Yep, exactly @vsoch! We need to still discuss how best to determine image equality. It is a good question and it needs answering!