Downloaded a folder from Google Drive, folder had epoch as modification date, crashed exa. Modified date on folder and worked again.
~/work ๎ฐ ls
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError(3600s)', src/libcore/result.rs:997:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[1] 18266 abort (core dumped) exa --long --header --git
โ ๎ฐ ~/work ๎ฐ RUST_BACKTRACE=full ls
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError(3600s)', src/libcore/result.rs:997:5
stack backtrace:
0: 0x5654a58cc913 - <unknown>
1: 0x5654a58cad7b - <unknown>
2: 0x5654a58c9da0 - <unknown>
3: 0x5654a58c998d - <unknown>
4: 0x5654a58d6e85 - <unknown>
5: 0x5654a58dadeb - <unknown>
6: 0x5654a58aa3cf - <unknown>
7: 0x5654a588d7f6 - <unknown>
8: 0x5654a58911d6 - <unknown>
9: 0x5654a58b795c - <unknown>
10: 0x5654a58b81ed - <unknown>
11: 0x5654a58d690d - <unknown>
12: 0x5654a58d78d7 - <unknown>
13: 0x7fb6819de57e - start_thread
14: 0x7fb6818f40e2 - __clone
15: 0x0 - <unknown>
[1] 17897 abort (core dumped) RUST_BACKTRACE=full exa --long --header --git
โ ๎ฐ ~/work ๎ฐ /bin/ls -la
total 12
drwxr-xr-x 3 bant bant 4096 Jul 30 14:26 .
drwx------ 34 bant bant 4096 Jul 30 14:26 ..
drwxr-xr-x 2 bant bant 4096 Jan 1 1970 ifdcerts
~/work ๎ฐ date
Tue Jul 30 14:27:11 IST 2019
~/work ๎ฐ touch -t 201907301429.00 ifdcerts
โ ๎ฐ ~/work ๎ฐ ls
Permissions Size User Date Modified Name
drwxr-xr-x - bant 30 Jul 14:29 ifdcerts
โ ๎ฐ ~/work ๎ฐ screenfetch
โโโโโโโโโโโโโโโโโโ โโโโโโโโ bant@floyd-work
โโโโโโโโโโโโโโโโโโ โโโโโโโโ OS: Manjaro 18.0.4 Illyria
โโโโโโโโโโโโโโโโโโ โโโโโโโโ Kernel: x86_64 Linux 4.19.59-1-MANJARO
โโโโโโโโโโโโโโโโโโ โโโโโโโโ Uptime: 4d 6h 23m
โโโโโโโโ โโโโโโโโ Packages: 1179
โโโโโโโโ โโโโโโโโ โโโโโโโโ Shell: zsh 5.7.1
โโโโโโโโ โโโโโโโโ โโโโโโโโ Resolution: 1920x1200
โโโโโโโโ โโโโโโโโ โโโโโโโโ DE: KDE 5.60.0 / Plasma 5.16.3
โโโโโโโโ โโโโโโโโ โโโโโโโโ WM: KWin
โโโโโโโโ โโโโโโโโ โโโโโโโโ GTK Theme: Breath [GTK2/3]
โโโโโโโโ โโโโโโโโ โโโโโโโโ Icon Theme: maia
โโโโโโโโ โโโโโโโโ โโโโโโโโ Font: Noto Sans Regular
โโโโโโโโ โโโโโโโโ โโโโโโโโ CPU: Intel Core i7-8650U @ 8x 4.2GHz [53.0ยฐC]
โโโโโโโโ โโโโโโโโ โโโโโโโโ GPU: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2)
RAM: 9425MiB / 15918MiB
I can't reproduce this. I'm wondering if there's any chance that the time zone matters, since I'm in PDT, though that would be quite odd.
The following ruby script should help to repro this
require 'fileutils'
FileUtils.touch 'thefile', mtime:-6795364578
It seems attempting to display any negative time will crash exa
Ok so the issue is specifically with a pre-epoch date.
Here's the full backtrace I get:
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError(1s)', src/libcore/result.rs:997:5
stack backtrace:
0: 0x104789e63 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h87b890447c1523f6
1: 0x10478cf3c - std::panicking::default_hook::{{closure}}::h4a96eb310410f198
2: 0x10478c24d - std::panicking::rust_panic_with_hook::hf7447e5ce429efbd
3: 0x10478be3c - std::panicking::continue_panic_fmt::h05a9fe8d80a29a99
4: 0x10478e4e8 - rust_begin_unwind
5: 0x1047a1cb9 - core::panicking::panic_fmt::h0a3c4c439e7d4c91
6: 0x10476cda2 - core::result::unwrap_failed::h4685bc8fc31c6716
7: 0x10475357c - exa::output::table::Table::display::h19e53ef39b994551
8: 0x104754644 - <F as scoped_threadpool::FnBox>::call_box::ha1a3105b48b83cd4
9: 0x10477aceb - std::sys_common::backtrace::__rust_begin_short_backtrace::h65bca5bd4c5f5fa9
10: 0x10477b687 - std::thread::Builder::spawn_unchecked::{{closure}}::h0df9091a076b1033
11: 0x1047891cc - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h8518f6a018469b37
12: 0x10478eba6 - std::sys::unix::thread::Thread::new::thread_start::h6d5d9d6994ec4ded
13: 0x7fff6efef2ea - _pthread_body
14: 0x7fff6eff2248 - _pthread_start
It seems to be only negative times. For reasons that are beyond me the hugo site generator set the example date I provided on some files. I don't suppose such times are common, but it's sure annoying to crash when trying to list a directory.
It's only on negative times, because the crash comes from code that converts from a platform-specific representation of creation/modification time into an epoch-based date, and the type being converted to is an unsigned integer. The error value in question (SystemTimeError(1s)) means "the value you wanted is 1s below the reference point you tried to create a Duration relative to".
I am rather confused as to why the platform-agnostic representation of time is an unsigned delta from a known epoch, given the fact that this prevents you from representing times before the epoch.
For Exa to fix this I think it will need to switch away from representing these times as Duration and instead represent them as Result<Duration, SystemTimeError> (the result of sys_time.duration_since(UNIX_EPOCH)), and then teach the formatting code how to handle this.
Same issue occurred, but was rather parrot related...
Anyway, I am able to reproduce the issue like this:
# user@work in ~/Downloads [15:50:29]
$ touch -d 19700101 exa-doesnt-like-this
# user@work in ~/Downloads [15:50:47]
$ exa -l
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: SystemTimeError(3600s)', src/libcore/result.rs:997:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[1] 24697 abort (core dumped) exa -l
# user@work in ~/Downloads [15:50:54] C:134
$ stat exa-doesnt-like-this
File: exa-doesnt-like-this
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 10303h/66307d Inode: 269392826 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/user) Gid: ( 1000/user)
Access: 1970-01-01 00:00:00.000000000 +0100
Modify: 1970-01-01 00:00:00.000000000 +0100
Change: 2019-08-19 15:50:47.280848292 +0200
Birth: 2019-08-19 15:50:47.280848292 +0200
$ exa -v
exa v0.9.0
kernel:
5.2.8-1-MANJARO
Same:
$ exa -alh --color=auto --group-directories-first --git
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.
zsh: abort (core dumped) exa -alh --color=auto --group-directories-first --git
$ stat css
File: css
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: fe05h/65029d Inode: 5773267 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 1000/ creshal) Gid: ( 1000/ creshal)
Access: 2019-08-20 10:19:33.378828024 +0200
Modify: 1754-08-30 23:49:02.128654848 +0105
Change: 2019-08-20 10:19:07.221898689 +0200
Birth: 2018-08-25 12:34:45.120701675 +0200
$ exa -v
exa v0.9.0
Is an mtime of 1754 silly? Yes. But it shouldn't crash exa.
I have the same problem.
File with access date 01.01.1970 crashes exa with SystemTimeError(3600s)
I guess because my time zone is -1 it tries to get the universal time and lands in a negative time.
The fix for this (#670) has been merged and will go out with the next release.
Most helpful comment
The following ruby script should help to repro this
It seems attempting to display any negative time will crash exa