<div dir="ltr"><div><div>Hello,<br><br></div>I'm currently leading a research project on deterministic execution of programs. We're developing a tool to enforce determinism dynamically on arbitrary code. Inodes are a easy way to uniquely identify files within our execution, so our runtime virtualizes inodes by mapping them to unique deterministic values, and I noticed inconsistencies from the results of getdents, getdents64 vs stat.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 9, 2018 at 6:12 PM, Chris Lamb <span dir="ltr"><<a href="mailto:lamby@debian.org" target="_blank">lamby@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Omar,<br>
<br>
> When using disorderfs the inodes returned by a system call to getdents are<br>
> all the same value<br>
[…]<br>
> This leads to an inconsistent state between inodes as well as breaking<br>
> assumptions programs might make about unique inodes when checking the<br>
> results of getdents.<br>
<br>
Heh. How did you spot this? Or rather, what application/foo makes<br>
these assumptions?<br>
<br>
(Just curious. I mean, we use disorderfs a *lot* in the reproducible<br>
builds project and don't appear to have hit this before.)<br>
<br>
<br>
Best wishes,<br>
<span class="HOEnZb"><font color="#888888"><br>
-- <br>
      ,''`.<br>
     : :'  :     Chris Lamb<br>
     `. `'`      <a href="mailto:lamby@debian.org">lamby@debian.org</a> / <a href="http://chris-lamb.co.uk" rel="noreferrer" target="_blank">chris-lamb.co.uk</a><br>
       `-<br>
</font></span></blockquote></div><br></div>