cargo: Fresh install unable to install anything

Here is what I see with verbose. I get this trying to install clippy or rustfmt. I assume I would get it with other crates.

Updating registry https://github.com/rust-lang/crates.io-index error: [20/-1] Cannot checkout to invalid path ‘3/n/nul’

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 24 (15 by maintainers)

Most upvoted comments

This is a Windows bug and not a problem with the crate name.

We can’t pass the buck on to windows like that. Yes, it is a windows bug. Windows won’t change it and certainly not in a timeframe that solves the current breakage. It is our responsibility to fix it, regardless of the entity that can be blamed for the bug. Fixing a bug does not necessitate self-assigning fault for it.

ping @alexcrichton @carols10cents not sure who else

We probably need to delete this crate and add all of these windows reserved names to the list of reserved names in crates.io.

Yay. NUL is a reserved name.

Other names to avoid / handle:

Do not use the following reserved names for the name of a file: CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9:

source: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

A more robust way to address these kinds of problems on Windows might be to do your own path normalization before calling any Win32 or C filesystem APIs. A fully qualified absolute path like \\?\C:\nul\aux\prn\whatever gets minimal Win32-level processing before getting handed off to the NT layer where these legacy device names aren’t a problem. Another benefit is that \\?\ paths can be up to 32768 TCHARs long instead of only MAX_PATH.

I don’t think any names that some OS does not allow, should be banned. This is a Windows bug and not a problem with the crate name.

@jckarter the error message seems to indicate that its during the git checkout that the issue occurs; not from within Cargo’s own code. Perhaps there’s an underlying issue with git / libgit?

This issue cannot be fixed by blacklisting crate names on crates.

Cargo uses a trie, so you could always trigger the trie to break via things like uploading packages nula, nulb,… so that a nul folder is created in the filesystem trie. We need a crates trie blacklist that makes sure these folder names don’t get created in the trie (falling back to storing them flat one level above), as well as blacklists for the existing name.

Unless I’m misunderstanding how the registry trie works.

@Manishearth The trie is 2 letters, so a crate named nula would go in nu/la. Idk if that still leaves problematic files

Deploying to production of the crates.io pr starting now.

What will happen is if there are any updates to the nul crate after the deploy, those updates won’t work. Which I think is fine. I’d rather prevent more things that cause problems first.