OS.FileSys.mkDir raises [overflow] error when invoked inside `binpash/try`

[Forthoney]

I'm getting an unexpected and rather strange [overflow] exception from a call to OS.FileSys.mkDir when my program is invoked inside try.

You can see the minimal reproducible code here, as well as the github actions runs for a run without try that completes as expected and a run with try that results in an overflow somehow.

I'm not particularly knowledgeable about try, but my hunch is that this has something to do with unshare, overlayfs which try uses under the hood not playing nicely with MLton.

It also may be the case that this is an issue with try, but try is specifically made to sandbox and observe file system changes, so I think it's less likely.

[YawarRaza7349]

This also happens in C, so it's not a MLton issue.

---

EDIT: To figure out the real issue, this might be a good place to start.

On 64bit systems, even if all overlay layers are not on the same underlying filesystem, the same compliant behavior could be achieved with the “xino” feature. The “xino” feature composes a unique object identifier from the real object st_ino and an underlying fsid number. The “xino” feature uses the high inode number bits for fsid, because the underlying filesystems rarely use the high inode number bits. In case the underlying inode number does overflow into the high xino bits, overlay filesystem will fall back to the non xino behavior for that inode