`cargo package` doesn't properly handle unreadable directories in the root

[konstin]

Problem

Cargo trips over an unreadable directory in the root instead of ignoring is like other irrelevant directories. This causes both cargo and downstream tools such as maturin to fail in an otherwise buildable project (PyO3/maturin#2777).

Steps

Create a project with an unreadable directory - Say one created by a docker container running as root. foo is the unreadable directory, bar is the readable control:

mkdir proj
cd proj
cargo init --vcs none --lib
mkdir foo
chmod 000 foo
mkdir bar

Unlike other directories, foo is included in the file list:

$ cargo package --list
warning: manifest has no description, license, license-file, documentation, homepage or repository
  |
  = note: see https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info
Cargo.lock
Cargo.toml
Cargo.toml.orig
foo
src/lib.rs

This subsequently fails builds, both for cargo and downstream for maturin:

$ cargo package
warning: manifest has no description, license, license-file, documentation, homepage or repository
  |
  = note: see https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info
   Packaging proj v0.1.0 (/home/konsti/projects/proj)
error: failed to prepare local package for uploading

Caused by:
  failed to open for archiving: `/home/konsti/projects/proj/foo`

Caused by:
  Permission denied (os error 13)

There's a separate issue where cargo's cargo package git integration fails with such a directory, while the git CLI only warns, but that's a separate problem.

Possible Solution(s)

No response

Notes

No response

Version

$ cargo --version
cargo 1.92.0 (344c4567c 2025-10-21)
$ cargo +nightly --version
cargo 1.94.0-nightly (b54051b15 2025-12-30)

[epage]

For me, the big question is how is cargo supposed to know whether the directory contains content meant to be packaged and it is a bug that it has the wrong permissions or if it shouldn't be packaged. Generally that should be through include / exclude / .gitignore and so the question is then how does this behave in the presence of the use of those features.

There's a separate issue where cargo's cargo package git integration fails with such a directory, while the git CLI only warns, but that's a separate problem.

As in an Issue exists or that it is an problem?

[konstin]

For me, the big question is how is cargo supposed to know whether the directory contains content meant to be packaged and it is a bug that it has the wrong permissions or if it shouldn't be packaged. Generally that should be through include / exclude / .gitignore and so the question is then how does this behave in the presence of the use of those features.

My suspicion was that there's some check in cargo that doesn't check is_dir to exclude the directory, at least that was happening in maturin. The pattern of top level unreadable dirs is kinda common if you work with docker containers.

As in an Issue exists or that it is an problem?

A separate bug. If you run the MRE from above without --vcs none, you get an (earlier?) rust-style error about git not been able to read the directory, while git status only warns. I just haven't gotten to writing that up properly.

[weihanglo]

The pattern of top level unreadable dirs is kinda common if you work with docker containers.

I am not familiar with it. Could you elaborate? Thanks.

[epage]

The pattern of top level unreadable dirs is kinda common if you work with docker containers.

But how is Cargo to know whether that was intentional or not?

[konstin]

The pattern of top level unreadable dirs is kinda common if you work with docker containers.

I am not familiar with it. Could you elaborate? Thanks.

When I need a specific linux distro or specific packages, I use docker run --rm -it -w /io -v $(pwd):/io <image> in the project root. If this writes a directory, that directory is owned by root. Another case is working with fresh containers each time and keeping only a cache directory around, e.g. docker run --rm -it -v $(pwd)/docker-cache:/app/cache or rust projects docker run --rm -it -v $(pwd)/target-docker:/app/target.

The pattern of top level unreadable dirs is kinda common if you work with docker containers.

But how is Cargo to know whether that was intentional or not?

Maybe I'm just misunderstanding how cargo include/excludes work, my naive idea was that cargo by default can skip over both foo and bar cause neither would end up in the package anyway, which only includes Cargo.{toml,toml.orig,lock}, src and a bunch of readme, license and assorted metadata files.

[epage]

The pattern of top level unreadable dirs is kinda common if you work with docker containers.

But how is Cargo to know whether that was intentional or not?

Maybe I'm just misunderstanding how cargo include/excludes work, my naive idea was that cargo by default can skip over both foo and bar cause neither would end up in the package anyway, which only includes Cargo.{toml,toml.orig,lock}, src and a bunch of readme, license and assorted metadata files.

From https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields

The default if neither field is specified is to include all files from the root of the package, except for the exclusions listed below.

So by default, Cargo will look in foo and bar for files to include in the .crate.

[konstin]

I see! In that case, I'm surprise that cargo package --list passes, given that trying to list the files inside foo to include failed.

[epage]

Something is likely confusing it into treating it as a file

[TanmayArya-1p]

This block of code seems to be responsible for adding the foo directory to the list_files_walk result. The directory path passes the filter since its not excluded and no include list is specified:

cargo/src/cargo/sources/path.rs

Lines 938 to 952 in 8c133af

	Err(err) => match err.path() {
	// If an error occurs with a path, filter it again.
	// If it is excluded, Just ignore it in this case.
	// See issue rust-lang/cargo#10917
	Some(path) if !filter(path, path.is_dir()) => {}
	// Otherwise, simply recover from it.
	// Don't worry about error skipping here, the callers would
	// still hit the IO error if they do access it thereafter.
	Some(path) => ret.push(PathEntry {
	path: path.to_path_buf(),
	ty: FileType::Other,
	under_symlink_dir: false,
	}),
	None => return Err(err.into()),
	},

Since the intention of this was to defer validation of doubtful paths to the callsite, we could maybe fix this by simply checking the paths in prepare_archive which is called when cargo package is run.

[epage]

@TanmayArya-1p keep in mind, there is the higher level question of whether we should be ignoring directories we can't read or error.