Exa: thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError()
I got this error when ran exa --group-directories-first -l.
The full stacktrace:
RUST_BACKTRACE=full ll
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError(6795364578.871345152s)', src/libcore/result.rs:1084:5
stack backtrace:
0: 0x104174ba2 - std::panicking::default_hook::{{closure}}::h3f994bbc901f9889
1: 0x104174219 - std::panicking::rust_panic_with_hook::hd3c20890ac648923
2: 0x104178e4d - std::panicking::continue_panic_fmt::hf444d349a369432b
3: 0x10417f099 - rust_begin_unwind
4: 0x10418890a - core::panicking::panic_fmt::h7bf9e431fd27d405
5: 0x10418ac29 - core::result::unwrap_failed::hcd64fedd568f6623
6: 0x1041385da - exa::output::table::Table::display::hcf507b282668020d
7: 0x10414b845 - <F as scoped_threadpool::FnBox>::call_box::h2476423e73c1c5c3
8: 0x1041657f2 - std::sys_common::backtrace::__rust_begin_short_backtrace::h936ac80d35975d5b
9: 0x10416603e - core::ops::function::FnOnce::call_once{{vtable.shim}}::h7b2406ae71a21381
10: 0x10417ecfd - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h04257f365502db2d
11: 0x10417f897 - std::sys::unix::thread::Thread::new::thread_start::haec1a494f7a7ae67
12: 0x7fff7650d2eb - _pthread_body
13: 0x7fff76510249 - _pthread_start
[1] 37488 abort RUST_BACKTRACE=full exa --group-directories-first -l
tataudat
All 11 comments
I'm facing this too, might have been due to rust being updated on my Arch machine:
-> exa -la
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError(6795364578.871345152s)', src/libcore/result.rs:997:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[2] 1875085 abort (core dumped) exa -la
aksh1618
on 13 Oct 2019
Appears like file timestamps of anything older than unix time 0 explode
self.metadata.modified().unwrap().duration_since(UNIX_EPOCH).unwrap() -> https://doc.rust-lang.org/std/time/struct.SystemTimeError.html
A SystemTimeError is returned from the duration_since method of SystemTime whenever the second system time represents a point later in time than the self of the method call.
So...
https://github.com/ogham/exa/blob/89c861f24d18650fc3cef50900e3341b5b038ccf/src/fs/file.rs#L330-L332
https://github.com/ogham/exa/blob/89c861f24d18650fc3cef50900e3341b5b038ccf/src/fs/file.rs#L340-L342
and
https://github.com/ogham/exa/blob/89c861f24d18650fc3cef50900e3341b5b038ccf/src/fs/file.rs#L345-L347 need to be rewritten, as mtimes etc. can be negative, apparently.
coderobe
on 7 Nov 2019
Hi,
I ran into the same issue, because of a wrong unix timestamp. I've fixed this for me with setting the right time.. I have no idea why the public-directory has suddenly a timestamp from the 17th century
chris motoko ~/export/github/nullday.de 22:29:16 2ff11afd master
> \ls -la
drwxr-xr-x 11 chris chris 4096 Aug 30 1754 public
chris motoko ~/export/github/nullday.de 22:29:20 2ff11afd master
> rm -rf public
chris motoko ~/export/github/nullday.de 22:30:09 2ff11afd master
> hugo --minify
| EN
+------------------+----+
Pages | 34
Paginator pages | 0
Non-page files | 0
Static files | 94
Processed images | 0
Aliases | 0
Sitemaps | 1
Cleaned | 0
Total in 215 ms
chris motoko ~/export/github/nullday.de 22:30:13 2ff11afd master
> ls -la
drwxr-xr-x - chris 7 Nov 22:30 public
shibumi
on 7 Nov 2019
Similar here, when invoked with the --long flag:
% RUST_BACKTRACE=full exa --long
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError(6795364578.871345152s)', src/libcore/result.rs:999:5
stack backtrace:
0: 0x10c06eee3 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h9ee514c692b21f1f
1: 0x10c0634b4 - std::panicking::default_hook::{{closure}}::h965a565a39a5c6a6
2: 0x10c0627cd - std::panicking::rust_panic_with_hook::hfb66282f4c2ad4bd
3: 0x10c0623bc - std::panicking::continue_panic_fmt::h968476d35e0218a2
4: 0x10c064998 - rust_begin_unwind
5: 0x10c077869 - core::panicking::panic_fmt::h9ae3f9e1e367adff
6: 0x10c03f5d2 - core::result::unwrap_failed::h02e6997b0638db69
7: 0x10c02477f - exa::output::table::Table::display::h0126c180bedcd47c
8: 0x10c0293d5 - <F as scoped_threadpool::FnBox>::call_box::hded7cbd175ad9dc1
9: 0x10c051d8e - std::sys_common::backtrace::__rust_begin_short_backtrace::h0b2895b91c97f366
10: 0x10c0523fa - core::ops::function::FnOnce::call_once{{vtable.shim}}::h55da96ad0c0b45da
11: 0x10c06f57c - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::hf9b88d2d2fe073fd
12: 0x10c06f356 - std::sys::unix::thread::Thread::new::thread_start::h34c632283a609b53
13: 0x7fff699b9d35 - _pthread_start
zsh: abort RUST_BACKTRACE=full exa --long
Here's my 18th-Century-timestamped directories — generated by the Hugo static site generator in my case:
dev master % ls -al --time-style=full-iso
total 332
drwxr-xr-x 19 jmromer staff 608 1754-08-30 17:47:40.-871345152 -0456.
drwxr-xr-x 16 jmromer staff 512 2019-11-23 08:55:47.738540066 -0500 ..
-rw-r--r-- 1 jmromer staff 6148 2019-11-10 23:22:56.509108176 -0500 .DS_Store
-rw-r--r-- 1 jmromer staff 18493 2019-11-23 11:37:14.594421670 -0500 404.html
drwxr-xr-x 6 jmromer staff 192 2019-11-23 08:55:47.785654936 -0500 blog
drwxr-xr-x 3 jmromer staff 96 2019-11-23 08:55:47.785697083 -0500 categories
drwxr-xr-x 17 jmromer staff 544 2019-11-23 08:55:47.786688930 -0500 commonplaces
drwxr-xr-x 8 jmromer staff 256 1754-08-30 17:47:40.-871345152 -0456fonts
drwxr-xr-x 5 jmromer staff 160 1754-08-30 17:47:40.-871345152 -0456images
drwxr-xr-x 17 jmromer staff 544 1754-08-30 17:47:40.-871345152 -0456img
-rw-r--r-- 1 jmromer staff 287595 2019-11-23 11:37:14.563237848 -0500 index.html
-rw-r--r-- 1 jmromer staff 10846 2019-11-23 11:37:14.596664002 -0500 index.xml
drwxr-xr-x 8 jmromer staff 256 1754-08-30 17:47:40.-871345152 -0456js
drwxr-xr-x 7 jmromer staff 224 2019-11-23 08:55:47.785620105 -0500 notes
-rw-r--r-- 1 jmromer staff 4012 2019-11-23 11:37:14.593931597 -0500 sitemap.xml
drwxr-xr-x 3 jmromer staff 96 2019-11-23 08:55:47.785651601 -0500 tags
img master % ls -al --time-style=full-iso
total 172
drwxr-xr-x 17 jmromer staff 544 1754-08-30 17:47:40.-871345152 -0456.
drwxr-xr-x 19 jmromer staff 608 1754-08-30 17:47:40.-871345152 -0456..
-rw-r--r-- 1 jmromer staff 6148 2019-11-10 15:55:13.467585519 -0500 .DS_Store
-rw-r--r-- 1 jmromer staff 1465 2019-11-10 21:43:48.289012555 -0500 500px.svg
-rw-r--r-- 1 jmromer staff 49530 2019-11-10 21:47:24.325165514 -0500 email.svg
Related issue: https://github.com/gohugoio/hugo/issues/6161
jmromer
on 10 Nov 2019
I'm also experiencing this issue since today's upgrade within Ubuntu Disco (19.10).
aapit
on 10 Dec 2019
Also happens with timestamps of 1970-01-01 00:00:00.000000000 +0100 (leads to SystemTimeError(3600s))
johnp
on 29 Dec 2019
I'm getting this same error. I'm not sure what's peculiar about the directory I'm in:
RUST_BACKTRACE=full exa -l
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError(6795364578.871345152s)', src/libcore/result.rs:1084:5
stack backtrace:
0: 0x105bcdced - std::panicking::default_hook::{{closure}}::hffc69ca72fa98b80
1: 0x105bcd7bc - std::panicking::rust_panic_with_hook::h058ef423beec40ce
2: 0x105bcdf7d - std::panicking::continue_panic_fmt::h0bb2cdb45a553955
3: 0x105bce249 - rust_begin_unwind
4: 0x105c5fdfa - core::panicking::panic_fmt::h2413d97d26203710
5: 0x105c60399 - core::result::unwrap_failed::hef33208e3f23e07a
6: 0x105b936bd - exa::output::table::Table::display::h7d61868c2e1aa281
7: 0x105ba6955 - <F as scoped_threadpool::FnBox>::call_box::hfeff2cdcb76e7a57
8: 0x105bbed6e - std::sys_common::backtrace::__rust_begin_short_backtrace::hf388fc36537a8fe9
9: 0x105bbf89e - core::ops::function::FnOnce::call_once{{vtable.shim}}::hd49318dcebc5ef76
10: 0x105bd813d - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::hf778f932793a5a82
11: 0x105bd8767 - std::sys::unix::thread::Thread::new::thread_start::ha4ccb7099fa6037f
12: 0x7fff6cc59e65 - _pthread_start
[1] 60977 abort RUST_BACKTRACE=full exa -l
mrichman
on 6 Mar 2020
Experiencing the same problem. I can see from #632 and @shibumi in this issue, is that they are (or seem to be) using Hugo.
It seems that Hugo is creating a weird modified timestamp, which can't be displayed by exa. When I run ls -la, I can see.
...
7083324 drwxr-xr-x 7 timo timo 4.0K Dec 13 1901 public/
When I do stat public, I get:
...
Access: 2020-03-21 12:49:41.390864562 +0100
Modify: 1901-12-13 21:05:24.000000000 +0019
Change: 2020-03-21 12:49:41.366864563 +0100
Birth: 2020-03-21 12:16:23.403962949 +0100
That modify date obviously is wrong. However, because ls works, this seems like this is both a bug in Hugo and a bug in exa.
There is a Hugo issue here.
timotk
on 21 Mar 2020
You're right. It's definitely a bug in both places:
gls --full-time
total 12
drwxr-xr-x 3 mark staff 96 2020-02-16 06:30:59.555450841 -0500 archetypes
-rw-r--r-- 1 mark staff 525 2020-03-06 08:04:43.117597473 -0500 config.toml
drwxr-xr-x 16 mark staff 512 2020-03-06 16:08:21.572223668 -0500 content
drwxr-xr-x 2 mark staff 64 2020-02-16 06:30:59.553838331 -0500 layouts
drwxr-xr-x 25 mark staff 800 2020-03-10 09:46:31.612696225 -0400 misc
drwxr-xr-x 34 mark staff 1088 1754-08-30 17:47:40.()/-,+/+. -0456 public
drwxr-xr-x 3 mark staff 96 2020-02-16 06:31:10.698866902 -0500 resources
drwxr-xr-x 2 mark staff 64 2020-02-16 06:30:59.554287527 -0500 static
drwxr-xr-x 4 mark staff 128 2020-02-23 21:07:28.949968144 -0500 themes
Look at that crazy timestamp for public!!!
Doing touch public fixes the issue.
mrichman
on 22 Mar 2020
Should be fixed in #670.
Freaky
on 19 May 2020
Yeah, this is #670. The fix has been merged and will go out with the next release.
ogham
on 21 Oct 2020
Related issues
simnalamburt
·
6Comments
skyzyx
·
4Comments
atomi
·
5Comments
grigorii-horos
·
4Comments
photex
·
4Comments
Most helpful comment
Hi,
I ran into the same issue, because of a wrong unix timestamp. I've fixed this for me with setting the right time.. I have no idea why the
public-directory has suddenly a timestamp from the 17th century