Lsd: thread 'main' panicked at 'failed to get the group name', libcore/option.rs:1008:5

Created on 10 Dec 2018 · 13Comments · Source: Peltoche/lsd

I got this error msg after installing rustfmt(Don't know if this matters).

env: macOS 10.12.6 with rustup 1.16.0 and cargo 1.31.0

The detail is:

thread 'main' panicked at 'failed to get the group name', libcore/option.rs:1008:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::option::expect_failed
   9: <lsd::meta::owner::Owner as core::convert::From<&'a std::fs::Metadata>>::from
  10: lsd::meta::Meta::from_path
  11: lsd::core::Core::list_folder_content
  12: lsd::core::Core::run_inner
  13: lsd::core::Core::run
  14: lsd::main
  15: std::rt::lang_start::{{closure}}
  16: std::panicking::try::do_call
  17: __rust_maybe_catch_panic
  18: std::rt::lang_start_internal
  19: main

kinbug

Source

kemingy

All 13 comments

Hi @kemingy,

Thanks for the report, can you give us the output from the classic \ls -la please?

Peltoche on 10 Dec 2018

Hi, I find this command always panic except for some root paths like /, /bin.
An empty folder is OK. But even with one file, like README.md, hello or test.txt file will cause panic.

An example:

> ls -la                                                                                                                       
total 0
drwxr-xr-x  3 keming.yang  1032302077  102 Dec 10 20:48 .
drwxr-xr-x  9 keming.yang  1032302077  306 Dec 10 20:47 ..
-rw-r--r--  1 keming.yang  1032302077    0 Dec 10 20:48 test.txt

Or with a folder like

> ls -la                                                                                                                        
total 0
drwxr-xr-x   3 keming.yang  1032302077  102 Dec 10 20:51 .
drwxr-xr-x  10 keming.yang  1032302077  340 Dec 10 20:51 ..
drwxr-xr-x   2 keming.yang  1032302077   68 Dec 10 20:51 css

This command lsd works well when I installed it yesterday(haven't reboot machine). I have tried cargo install lsd --force but didn't work.

kemingy on 10 Dec 2018

In your previous error message, lsd failed to retrieve your group name. This can be due to the use std::os::unix::fs::MetadataExt;. A friend just tried on OSX and everything seems to work fine.

If you build fail, can you send us the error message please?

Peltoche on 10 Dec 2018

Hi, thanks for your advice.
I try to replace Owner::from with

impl Owner {
    pub fn new() -> Self {
        let user = get_current_username()
            .expect("failed to get user name")
            .to_string_lossy()
            .to_string();

        let group = get_current_groupname()
            .expect(">>> failed to get group name")
            .to_string_lossy()
            .to_string();

        Owner { user, group }
    }
}

and get error, too.

Then I create a new project to test it. It seems I cannot run users::get_current_groupname correctly. I test it on my another computer and it goes well. Don't know what happend to my own env or users lib.

thread 'main' panicked at '', libcore/option.rs:1008:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at libstd/panicking.rs:476
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: std::panicking::try::do_call
             at libstd/panicking.rs:325
   7: core::ptr::drop_in_place
             at libcore/panicking.rs:77
   8: core::ptr::drop_in_place
             at libcore/option.rs:1008
   9: <core::option::Option<T>>::expect
             at libcore/option.rs:322
  10: rust_test::main
             at src/main.rs:7
  11: std::rt::lang_start::{{closure}}
             at libstd/rt.rs:74
  12: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  13: macho_symbol_search
             at libpanic_unwind/lib.rs:102
  14: std::alloc::default_alloc_error_hook
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  15: std::rt::lang_start
             at libstd/rt.rs:74
  16: rust_test::main

kemingy on 11 Dec 2018

Sorry, this should be some problem with my own environment.

kemingy on 12 Dec 2018

Sorry, I have absolutely no clue of what is going on...

Maybe you groupname is invalid in some way or the users module doesn't handle correctly your case. You probably should create an issue at https://github.com/ogham/rust-users.

Peltoche on 12 Dec 2018

Thanks for your help. I'll do it.

kemingy on 12 Dec 2018

Finally, I found it's because of my VPN. Not sure what VPN does. But every time this happens, just turn off and turn on VPN will solve it.
Thanks for your help.

kemingy on 13 Dec 2018

WUT ??!! Really curious...

Peltoche on 13 Dec 2018

This happens to me inside of ZFS root or filesystems (but not in subfolders)