fix: detect infinite file system loop and bail out

[weihanglo]

What does this PR try to resolve?

For #9528 if the loop in inside /sys/block it would be an infinite loop.
In that case Cargo is better bailing out instead of emitting endless warnings.
We set a relatively large limit 1024
to ensure there is any legitimate reason to have file system loop.

This also turn the file system loop warning into a debug! log, per #12600 request.

How should we test and review this PR?

I don't really know if 1024 is really a big enough number.
My naive instinct told me that there is no a valid use case for so many loops in a Cargo package.

Additional information

Fixes #12600

[rustbot]

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

For myself, I'd like to better understand more about the use case before moving forward.

[weihanglo]

For myself, I'd like to better understand more about the use case before moving forward.

While this is a fix of #12600, it is also a solution to #9528 (comment). Fixing #12600 is more like a side effect.

The warning of file system loop was a solution to let people know they are stuck in infinite loop (#9528). However endless warnings are not particularly useful. Especially if it happens in CI and then users need to wait for CI service timing out, which could be hours. Breaking the loop is more pragmatic than that I believe.

[ijackson]

By "bail out" I hope we mean "skip the recursion and continue scanning other files" rather than "fai".

Currently I'm getting these warnings but I just want them suppressed, not to become fatal. See #12600

[weihanglo]

@ijackson

We set a relatively large limit 1024
to ensure there is any legitimate reason to have file system loop.

Unsure whether 1024 is large enough to say that you have an “infinite file system loop”. Can increase it if you have a use case that loops back to the same directory more than 1024 times.

[ijackson]

@ijackson

We set a relatively large limit 1024
to ensure there is any legitimate reason to have file system loop.

Unsure whether 1024 is large enough to say that you have an “infinite file system loop”. Can increase it if you have a use case that loops back to the same directory more than 1024 times.

I'm not sure I follow. In one of my use cases I have, for example, a symlink maint -> .

Every time you try to follow it, it will come back to the same directory.

Currently I'm getting a warning about this, but cargo seems to function. If this warning becomes an error my project will become unbuildable.

The value of 1024 doesn't seem relevant.

(edited to clarify formatting)

[epage]

From my reading of the code and walkdir, the 1024 is more of a "if you find 1024 unique symlinks pointing to an ancestor, bail". Putting a cap on that seems like an odd solution.

That was the solution proposed in #9528 (comment) but that comment is overall light on details and solution seems more focused on "error rather than make my CI slow" which seems like a false dichotomy and that we should explore other solutions. As that person didn't create an issue, should we continue that conversation over at #12600 (as our PRs are generally more focused on the implementation than problem/solution discussions)?

[weihanglo]

From my reading of the code and walkdir, the 1024 is more of a "if you find 1024 unique symlinks pointing to an ancestor, bail". Putting a cap on that seems like an odd solution.

Agree that it is just a random cap. #12235 is probably one solution to it. Let's close this PR and discuss in #12600 then.