exa 0.9 panicked on Result:unwrap() when there is a broken symlink

[number5]

λ exa --git -l
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:999:5
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: rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::result::unwrap_failed
   7: exa::fs::feature::git::reorient
   8: exa::fs::feature::git::Git::status
   9: exa::output::table::Table::display
  10: <F as scoped_threadpool::FnBox>::call_box
[1]    79857 abort      exa -l --git

This only happens with both --git and -l options, exa or exa --git looks good

Steps to reproduce:

git init exa_test
cd exa_test
ln -s /non-exist-file .
exa --git -l

[rpdelaney]

Yeah I just came here to post this except I hadn't identified the cause. Good job running that down.

$ exa --version
exa v0.9.0
$ RUST_BACKTRACE=1 exa --long --header --git --links --group-directories-first --color-scale --time-style=long-iso
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:999:5
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: rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::result::unwrap_failed
   7: exa::fs::feature::git::reorient
   8: exa::fs::feature::git::Git::status
   9: exa::output::table::Table::display
  10: <F as scoped_threadpool::FnBox>::call_box
Abort trap: 6
$ 

[ghost]

emacs backup files (e.g. .#file.ext) also cause this issue to be triggered.

[tiffon]

Seems like it only happens when both the -l and --git flags are used.

Using the steps to reproduce above:

$ exa -l
lrwxr-xr-x 15 joe 25 Aug 23:25 non-exist-file -> /non-exist-file

$ exa --git
non-exist-file

$ exa --git -l
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:999:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
Abort trap: 6

[flokli]

Stacktrace:

#0  0x00007fa85d51dbe0 in raise () from /nix/store/iykxb0bmfjmi7s53kfg6pjbfpd8jmza6-glibc-2.27/lib/libc.so.6
[Current thread is 1 (Thread 0x7fa855422700 (LWP 29959))]
(gdb) bt
#0  0x00007fa85d51dbe0 in raise () from /nix/store/iykxb0bmfjmi7s53kfg6pjbfpd8jmza6-glibc-2.27/lib/libc.so.6
#1  0x00007fa85d51edc1 in abort () from /nix/store/iykxb0bmfjmi7s53kfg6pjbfpd8jmza6-glibc-2.27/lib/libc.so.6
#2  0x00005647b7462d17 in panic_abort::__rust_start_panic::abort ()
#3  0x00005647b7462d06 in __rust_start_panic ()
#4  0x00005647b7457126 in rust_panic ()
#5  0x00005647b74570ad in std::panicking::rust_panic_with_hook ()
#6  0x00005647b7456b9e in std::panicking::continue_panic_fmt ()
#7  0x00005647b7458b96 in rust_begin_unwind ()
#8  0x00005647b746f46c in core::panicking::panic_fmt ()
#9  0x00005647b743168b in core::result::unwrap_failed ()
#10 0x00005647b743432c in exa::fs::feature::git::reorient ()
#11 0x00005647b7433b01 in exa::fs::feature::git::Git::status ()
#12 0x00005647b7413edc in exa::output::table::Table::display ()
#13 0x00005647b741a1b2 in <F as scoped_threadpool::FnBox>::call_box ()
#14 0x00005647b7441ead in std::sys_common::backtrace::__rust_begin_short_backtrace ()
#15 0x00005647b7442818 in core::ops::function::FnOnce::call_once{{vtable-shim}} ()
#16 0x00005647b745532e in <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once ()
#17 0x00005647b74563c8 in std::sys::unix::thread::Thread::new::thread_start ()
#18 0x00007fa85d8bbef7 in start_thread () from /nix/store/iykxb0bmfjmi7s53kfg6pjbfpd8jmza6-glibc-2.27/lib/libpthread.so.0
#19 0x00007fa85d5db22f in clone () from /nix/store/iykxb0bmfjmi7s53kfg6pjbfpd8jmza6-glibc-2.27/lib/libc.so.6

[j-tai]

Duplicate of #526

[dingo-d]

When can we expect a release with a fix for this?

[snipem]

It is already fixed with #584 but has to be released.

[rpdelaney]

@snipem Thanks. Looks like we're coming up on 1 year since the last release. I wonder what's driving (or rather, not driving) the release cadence. For those of us who aren't building from the tip of master (e.g. installing via a package manager) this is a long time to wait.

[ariasuni]

This has been fixed and there are already several issues asking for a new release, so I’m closing this issue.