exa crash with --git switch

[eggbean]

I have been using this exa binary for years with no problems, at least for a long time.

jason@osiris:~/.ssh% exa --version
exa v0.9.0 ( built on 2021-07-28)
jason@osiris:~/.ssh% exa -l --git
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:1188:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "PoisonError { inner: .. }"', src/libcore/result.rs:1188:5
thread 'main' panicked at 'Thread pool worker panicked', /home/jason/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.9/src/lib.rs:236:13

/home/jason/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.9/src/lib.rs:236:13 ...doesn't exist, but it must have done when I compiled the binary.

I don't know what this means, but I thought I'd make a record of it.

[mentalisttraceur]

1. Your exa is a couple versions behind. Latest release is exa v0.10.1 so try upgrading and see if the issue still happens.

2. I'd like to you run the following test (ideally both before and after upgrading). You'll need to open two separate terminals for this. In the first terminal, start by creating and entering a test directory:

   $ mkdir ~/test
   $ cd ~/test

   Now, in the second terminal, delete the test directory:

   $ rmdir ~/test
   # You can also recreate it if you want. It won't change the
   # result. The other shell is still in the old, now-deleted
   # "~/test", not in whatever-directory-is-currently-at-"~/test".
   $ mkdir ~/test

   Finally, back in the first terminal, run Exa:

   $ exa

   In the latest version of Exa, that will error with ".": No such file or directory (os error 2), but I wonder/suspect your older Exa would produce the panic you saw.

3. The error is luckily self-explanatory, to those of us who can read the mystic programmer tea leaves. This part

   called `Result::unwrap()` on an `Err` value

   means that a line of code somewhere in Exa got an error that it didn't check for. Rust's safety checks kicked in and killed the program instead of letting it run off the rails and do things with a bad result as if it was a good result. And the error that it got but didn't check for was:

   Os { code: 2, kind: NotFound, message: "No such file or directory" }'`

   Those versed in the deeper magics recognize this as the system call error ENOENT - returned from system calls when we try to access something (for example, a file) that doesn't exist.

   One potentially misleading thing is that Rust prints the file names of where in the code the panic was raised, not the file it was trying to access when it first got the error.

[eggbean]

Thanks, but that turned out to be a one-off crash and it never happened again. I just thought it would be a good idea to make a record of it as it was unusual. I don't know why I was on an old version at that point. Maybe I was rebasing on my binary repo or something.

[mentalisttraceur]

Yeah, one-off is what I'd expect if it was caused by what I described in 2: it's pretty rare for someone to organically get in a situation where they delete(/recreate) a directory, while having another terminal/shell still in it, and then run ls/exa/whatever from there.

Anyway, cheers!

[eggbean]

Oh, I see. I did your test and got a different result, but now I use the stable nix package build (the unstable build appears to be from HEAD and has a bug where no more than one row can list horizontally),

jason@hydra:~% take test
jason@hydra:~/test% exa
direnv: error LoadConfig() Getwd failed: getwd: no such file or directory

I suppose the recreated directory with the same name obviously has a different inode number.