File System Loop Found - Rust >= 1.6

[Burtannia]

Problem

I've just been updating all of the dependencies in one of our apps at work and I've run into a strange problem. In order to get access to some more recent packages I've had to upgrade our Rust version to above 1.6 otherwise cargo complains about not being able to find the latest version of a package I'm trying to use. All of this compiled absolutely fine on my work machine (Mac). Unfortunately when run in a Docker image using various versions of rust-alpine I get the following error during dependency installation.

 => => # warning: File system loop found: /sys/class/thermal/cooling_device1/device/physical_node/driver/cpu3/firmware_node/subsystem/devices/PNP0B00:00/physical_node/wakeup/wakeup3/subsystem/wakeup0/device/physi
 => => # cal_node/subsystem/devices/0000:00:08.0/driver/0000:00:01.0/virtio0/subsystem/devices/virtio2/block/vda/vda1/subsystem/nbd13/bdi/subsystem/7:5/subsystem points to an ancestor /sys/class/thermal/cooling_d
 => => # evice1/device/physical_node/driver/cpu3/firmware_node/subsystem/devices/PNP0B00:00/physical_node/wakeup/wakeup3/subsystem/wakeup0/device/physical_node/subsystem/devices/0000:00:08.0/driver/0000:00:01.0/v
 => => # irtio0/subsystem/devices/virtio2/block/vda/vda1/subsystem/nbd13/bdi/subsystem 

I'm not sure whether this is a problem with cargo or not but, as you will see in the "Steps" section, I'm out of ideas at this point so I thought I'd come here seeking some help.

Steps

I've failed miserably at getting this to reproduce. I created a new Rust project with the exact same dependencies and it builds inside Docker absolutely fine. We also rely on an internal library which I also copied in as a dependency. I copied the lock files too and tried generating brand new lock files, deleting target etc. I've stripped down our multi-stage Docker file into just the build stage so it perfectly matches my new working project yet it still loops.

Here is a minimal Dockerfile which produces the issue:

FROM rust:1.66-alpine AS builder

COPY . .

RUN cargo build --release

This causes the issue with our app but not with my new hello-world app despite including all the same dependencies in the hello-world app.

I understand that without steps to reproduce this will probably be quite hard to solve but I would appreciate it if someone could at least offer some suggestions about what to do next.

Possible Solution(s)

No response

Notes

No response

Version

Work Machine:
cargo 1.66.0 (d65d197ad 2022-11-15)
release: 1.66.0
commit-hash: d65d197ad5c6c09234369f219f943e291d4f04b9
commit-date: 2022-11-15
host: x86_64-apple-darwin
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.85.0 (sys:0.4.55+curl-7.83.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 13.1.0 [64-bit]

Docker `rust:1.60-alpine`:
#11 0.676 cargo 1.60.0 (d1fd9fe2c 2022-03-01)
#11 0.676 release: 1.60.0
#11 0.676 commit-hash: d1fd9fe2c40a1a56af9132b5c92ab963ac7ae422
#11 0.676 commit-date: 2022-03-01
#11 0.676 host: x86_64-unknown-linux-musl
#11 0.676 libgit2: 1.3.0 (sys:0.13.23 vendored)
#11 0.676 libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1m)
#11 0.676 os: Alpine Linux 3.15.4 [64-bit]

Docker `rust:1.66-alpine`:
#11 0.538 cargo 1.66.0 (d65d197ad 2022-11-15)
#11 0.538 release: 1.66.0
#11 0.538 commit-hash: d65d197ad5c6c09234369f219f943e291d4f04b9
#11 0.538 commit-date: 2022-11-15
#11 0.538 host: x86_64-unknown-linux-musl
#11 0.538 libgit2: 1.5.0 (sys:0.15.0 vendored)
#11 0.538 libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1q)
#11 0.538 os: Alpine Linux 3.17.0 [64-bit]

[weihanglo]

The filesystem loop warning was introduced in 1.59 by #10188 and #10214. As it is only a warning, it shouldn't harm your build. Have you detected anything stopping the code from compiling?

From my understanding, there might be at least two possible causes.

• COPY . . might copy your package directly to filesystem root / without any other instruction. It is potentially risky since files under your projects might conflict with files of the system. A common trick is adding a WORKDIR instruction. Here is an example from crates.io
• If your project contains a build script or is not under any source control, Cargo by default walks every file of your filesystem, so it got confused when seeing system devices loops. You could leverage package.include in Cargo.toml or add a cargo:rerun-if-changed accordingly to prevent filesystem walking.

I believe the first one can solve it immediately.

[Burtannia]

The filesystem loop warning was introduced in 1.59 by #10188 and #10214. As it is only a warning, it shouldn't harm your build. Have you detected anything stopping the code from compiling?

From my understanding, there might be at least two possible causes.

• COPY . . might copy your package directly to filesystem root / without any other instruction. It is potentially risky since files under your projects might conflict with files of the system. A common trick is adding a WORKDIR instruction. Here is an example from crates.io
• If your project contains a build script or is not under any source control, Cargo by default walks every file of your filesystem, so it got confused when seeing system devices loops. You could leverage package.include in Cargo.toml or add a cargo:rerun-if-changed accordingly to prevent filesystem walking.

I believe the first one can solve it immediately.

Thanks for the reply! While the warning itself didn't stop the build, it did just keep spamming the warning and lagging my machine until it eventually crashed (I don't remember what the final error was since I just cancelled it myself every subsequent time I saw the warnings appear).

Your first suggestion did indeed fix the problem, thank you so much :)