Exa: Crash with epoch/1970 modification date on folder

Created on 30 Jul 2019  ยท  10Comments  ยท  Source: ogham/exa

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
errors โ€บ runtime error

Most helpful comment

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

All 10 comments

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.

Was this page helpful?
0 / 5 - 0 ratings