thread 'main' panicked at 'called Result::unwrap()

[gralpli]

I‘m getting

➜  ~ RUST_BACKTRACE=1 cargo cache
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 20, kind: Other, message: "Not a directory" }', src/libcore/result.rs:999:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::rust_panic_with_hook
   3: std::panicking::continue_panic_fmt
   4: rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::result::unwrap_failed
   7: cargo_cache::cache::registry_cache::RegistryCache::files
   8: cargo_cache::dirsizes::DirSizes::new
   9: cargo_cache::main
  10: std::rt::lang_start::{{closure}}
  11: main

on macOS 10.14.2.

[gralpli]

Ha! Found the error! There is a file “/Users/gralpli/.cargo/registry/cache/.DS_Store” on my system that is indeed no directory.

The function cargo_cache::cache::registry_cache::RegistryCache::files tries to fs::read_dir(&repo) (line 90) on this file which results in the panic.

Maybe you want ignore files starting with a dot throughout your program?

[matthiaskrgr]

Thanks for the the ticket.

This is interesting, it's probably the unwrap() of fs::read_dir(&self.path) but I'm curious why this fails...
I'll add some debugging code later today so we can see what file this happens for.

[jrmuizel]

I get

thread '<unnamed>' panicked at 'Failed to read directory of file: '"/Users/jrmuizel/.cargo/git/checkouts/panopticon-c2636b8a03012228/c738b31/examples"'', src/cache/git_checkouts.rs:83:45
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::rust_panic_with_hook
   3: std::panicking::continue_panic_fmt
   4: std::panicking::begin_panic_fmt
   5: cargo_cache::cache::git_checkouts::GitCheckoutCache::total_size::{{closure}}::{{closure}}
   6: rayon::iter::plumbing::bridge_producer_consumer::helper
   7: rayon_core::join::join_context::{{closure}}
   8: rayon::iter::plumbing::bridge_producer_consumer::helper
   9: rayon_core::join::join_context::{{closure}}
  10: rayon::iter::plumbing::bridge_producer_consumer::helper
  11: rayon_core::join::join_context::{{closure}}
  12: rayon::iter::plumbing::bridge_producer_consumer::helper
  13: rayon_core::join::join_context::{{closure}}
  14: rayon::iter::plumbing::bridge_producer_consumer::helper
  15: rayon_core::join::join_context::{{closure}}
  16: rayon::iter::plumbing::bridge_producer_consumer::helper
  17: <rayon_core::job::StackJob<L, F, R> as rayon_core::job::Job>::execute
  18: rayon_core::registry::WorkerThread::wait_until_cold

/Users/jrmuizel/.cargo/git/checkouts/panopticon-c2636b8a03012228/c738b31/examples is symlink to an non existent file

[matthiaskrgr]

So, I added some checks to make sure files actually exist and are not dead symlinks for example before querying size.

Could you please check with the git version if your crashes still occur?

[jrmuizel]

That fixes it for me.

[matthiaskrgr]

Awesome!
Does something like cargo cache -t 10 also work?

[jrmuizel]

Yes.

[matthiaskrgr]

Great! Thanks a lot! :D
I'll try to get out another release in a couple of hours.

[matthiaskrgr]

The problem was that I assumed the some directories would only contain files and some would only contain directories, thus simply looping over the contents of a directory and getting the filesize of every item or the contents of every subdirectory.

However, this panicked when I tried to get the length of a file that was a dead symlink or if the directory I queried for its content was a regular file (as it happened with these .DS_Store files.

The checks make sure that files are actually existing files and dirs are actually directories before proceeding. :)