Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The search for the config file ignores symlinks #1650

Open
Magnap opened this issue Jun 11, 2017 · 1 comment
Open

The search for the config file ignores symlinks #1650

Magnap opened this issue Jun 11, 2017 · 1 comment

Comments

@Magnap
Copy link

Magnap commented Jun 11, 2017

When placing a .rustfmt.toml file in my home directory (I realize you're meant to stay with the defaults globally, but wanted to switch to rfc style), I noticed it had no effect. Now, the folder my project was in is symlinked as ~, but is actually placed on a separate btrfs subvolume, so I suspected the recursive search upwards was failing to cross the filesystem boundary. Moving the file into the subvolume worked, but out of curiosity I searched through the issues, PRs, and source relating to config file search, and found that fs::canonicalize was being called on the current directory path before starting the search, which means that it will not respect what you see as the directory you are in if you arrived there through symlinks. Given the clear function of canonicalize, I expect this to be intentional, but is it? And if so, why?

(also, this my first time submitting an issue, so any feedback on the format is welcome)

@davidBar-On
Copy link
Contributor

Seems that the following options are available to resolve this issue:

  1. Add a note in the toml documentation about that behavior.
  2. Add a configuration option for whether moving up in the directories tree should be with or without the canonicalization. I am not sure this approach is useful and seems as an overkill.
  3. Search first without canonicalization and if a toml file is not found search using canonicalization. A configuration option can be used to set whether this approach is used.

The third option will solve the issue and is probably easy to implement (I can submit a PR if desired). However, since 5 years passed since the issue was opened and it seems that no one else complained about this issue, probably the first option (documentation) is the proper resolution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants
@nrc @Magnap @topecongiro @davidBar-On and others