Errors creating a canister with 'dfx deploy'

Hi @canicodenow!

I’m Roman, I authored most of the replica state snapshotting code.

Thanks a lot for reporting the issue! I’m sorry that your first experience with the replica wasn’t great at all. The replica was designed to work on any modern UNIX. Unfortunately, we haven’t tested it on HFS+ file system. Until today.

I was able to reproduce the issue you see by formatting a drive as HFS+ and running dfx on it. The patch with the fix is on the way!

Boring technical details

The error happens when the replica tries to create a snapshot of its state so that it doesn’t have to execute all the blocks from scratch if it restarts. The replica tries to leverage file cloning capabilities provided by modern filesystems to make snapshotting blazingly fast. If the filesystem doesn’t support that feature (few do), we fallback to standard file copying. What you observe is a bug in the fallback mechanism: if the file cloning syscall fails, Linux kernel returns EOPNOTSUPP error code, while macOS returns ENOTSUP. We handle the former but not the latter (it’s easy to confuse them, they are actually equal on Linux, but not on macOS), so the fallback code doesn’t work properly on macOS. The fix is a one-line code change here.

I’ll do my best to make sure that the next release of dfx includes a replica that works fine on your system. Please use the emulator option suggested by @prithvi until then.

Looking forward to seeing all the great things you’ll build on the Internet Computer.

Roman

7 Likes