Closed nikelborm closed 3 months ago
This is related to #666 and #735 and needs a fix in the standard library (https://github.com/rust-lang/rust/issues/108277)
Is there anything I can do to fix this or to help with fixing it if I don't know rust?
What we've seen before (you can have a look through the other reports if you like) is that it's usually a single file that causes the problem and it's often in the btime
field (file creation time, only supported on some file systems). If you can find the problematic file and re-create it, the issue should go away.
Unfortunately because the code that causes eza
to panic and exit is part of Rust itself, there's nothing we can do about it. We need to wait for someone to update the standard code to at least return an error for invalid timestamps rather than panicking. If you wanted to get into Rust you could help with that (see the latest comments in the Rust bug report) but it won't be simple!
There are no files only directories in my root (except few links, which are probably technically files, pointing to directories)
ls -la --time=birth
shows me a list of directories and links and now i discard my previous suspects in favor of a new ones, which have ?
in place of birthtime
total 36
drwxr-xr-x 1 root root 198 Dec 5 2022 .
drwxr-xr-x 1 root root 198 Dec 5 2022 ..
drwxr-xr-x 1 nikel nikel 10 Jan 5 16:59 _
lrwxrwxrwx 1 root root 7 Sep 24 07:19 bin -> usr/bin
drwxr-xr-x 1 root root 8 Dec 5 2022 boot
drwxr-xr-x 19 root root 4160 Jan 5 16:28 dev
drwxr-xr-x 1 root root 0 Jan 6 2023 efi
drwxr-xr-x 1 root root 4310 Nov 24 1833 etc
drwxr-xr-x 1 root root 10 Dec 17 2021 home
drwxr-xr-x 19 root root 4096 Jan 6 2023 kaliroot
dr-xr-xr-x 1 root root 0 ? keybase
lrwxrwxrwx 1 root root 7 Sep 24 07:19 lib -> usr/lib
lrwxrwxrwx 1 root root 7 Sep 24 07:19 lib64 -> usr/lib
drwxr-xr-x 1 root root 24 Dec 5 2022 mnt
drwxr-xr-x 1 nikel nikel 94 Jan 2 21:55 nikel_big_downloads
drwxr-xr-x 1 root root 228 Dec 5 2022 opt
dr-xr-xr-x 492 root root 0 ? proc
drwxr-x--- 1 root root 400 Dec 5 2022 root
drwxr-xr-x 33 root root 860 Jan 5 16:28 run
lrwxrwxrwx 1 root root 7 Sep 24 07:19 sbin -> usr/bin
drwxr-xr-x 1 root root 14 Dec 5 2022 srv
dr-xr-xr-x 13 root root 0 ? sys
drwxrwxrwt 22 root root 540 Jan 5 16:28 tmp
drwxr-xr-x 1 root root 80 Dec 5 2022 usr
drwxr-xr-x 1 root root 126 Dec 5 2022 var
Honestly I'm quite afraid to do any manipulations with /sys and /proc directory. I don't want to f**k up my system. So i have to wait then. Maybe it's even kernel bug because WTF those directories have ?
as birthtime
I'm facing a similar error that might be related: Error text:
thread 'main' panicked at /usr/share/cargo/registry/chrono-0.4.31/src/datetime/mod.rs:1418:38:
No such local time
if removing the --color-scale
the command works fine:
@iax7 You can track this issue to when they fix it and see if their update fixes your error. Because for me your error looks like something different from mine.
Even when it's fixed in the standard library we'll still have to depend on that through updating requirements to use the Rust version it's released in so it'll be a while before any fix gets to eza.
So there's a fix committed to the stdlib which will fix this once it makes it to stable and we update our MSRV to the version it's released in. From what I can see, there won't be any code changes needed on our end.
Might be a while until we get there thou... Although latest clap requires 1.75 so we should be getting closer soon
Oh, by the way, it works perfectly fine now 🎉🎉🎉 Thanks everybody involved in making it work fine
v0.17.0 [+git]
--long --color-scale=age
Error:
Successful execution when trying to color-scale by size. For me it looks like the error may be coming from
1 Jan 1970
when eza compares dates taken from mounted fat32 partitions (/boot, /efi)My mounted partitions if this matters: