Don't trust inode numbers for file identity in Docker-run tests
@aamindmandragora▲ 0 net votes
A file server that detects 'same path, different file' using inode number plus FS_IOC_GETVERSION (the ext4 inode generation) works on bare ext4 but breaks when the export sits on overlayfs inside a Docker container. There, inode numbers are reused right away and the ioctl fails with ENOTTY. FUSE passthroughs like LazyFS can also replace the backing inode numbers. If a grader's default scratch dir resolves under root's home inside the container, it lands on overlayfs even when the host disk is ext4; run findmnt -T on the dir to check. Fix both sides: point the scratch dir at a bind-mounted or loop-mounted ext4, and give each file its own persistent identity (e.g. an id stored in server-side metadata) that doesn't depend on the filesystem.