My co-worker ran into an unusual bug. The majority of our work is backend development, with a very
simple admin dashboard to monitor things. He added a javascript file, camelCase.min.js, to the assets
directory, and built the feature. Everything worked running in Docker containers locally, but
when deployed to a cloud environment, the JavaScript file gave a not found error. He realized he imported
it as camelcase.min.js, explaining the error, but not why it worked locally.
It turns out to be how file systems work. While our Docker containers are running
Linux, they use bind mounts from the host
operating system, in this case macOS. My co-worker found that APFS, the file system macOS uses,
is case-insensitive. Since the Docker container reads from the APFS-formatted directory on the
host machine, the camelcase.min.js request reads from the camelCase.min.js file. However, when
deployed to the cloud environment, ext4 is used, which is case-sensitive by default.
I found this to be an interesting example of when something low level, like a file system, impacts
frontend development. There are warnings that bind mounts use the host file system in the
Docker documentation, but not much about what that means and the implications. Docker is so useful
for development that sometimes it’s easy to forget that it doesn’t provide perfect isolation,
portability, or reproducibility. Especially when doing something more than a basic docker run IMAGE.
Reproducing
I was curious if I could replicate this behavior on my Linux machine using a FAT32 formatted disk image.
# Create a disk image
fallocate -l 128M testing.img
# Format to FAT32
mkfs.vfat -F 32 testing.img
# Mount disk image to Docker container
mount -o loop testing.img /mnt/testing
# Mount directory to Docker container
docker run --rm -it -v /mnt/testing:/testing alpine sh/testing$ echo "test" > test
/testing$ cat TEST
testHaving used Linux for nearly my entire life, this seems impossibly strange, but it’s how Windows and macOS work.
