Yazi uses term 'ctime' incorrectly

[majutsushi]

What system are you running Yazi on?

Linux X11

What terminal are you running Yazi in?

Kitty 0.36.1

yazi --debug output

Yazi
    Version: 0.3.3 (7c445ce 2024-09-04)
    Debug  : false
    OS     : linux-x86_64 (unix)

Ya
    Version: 0.3.3 (7c445ce 2024-09-04)

Emulator
    Emulator.via_env: ("xterm-kitty", "")
    Emulator.via_csi: Ok(Kitty)
    Emulator.detect : Kitty

Adapter
    Adapter.matches: Kitty

Desktop
    XDG_SESSION_TYPE           : Some("x11")
    WAYLAND_DISPLAY            : None
    DISPLAY                    : Some(":0")
    SWAYSOCK                   : None
    HYPRLAND_INSTANCE_SIGNATURE: None
    WAYFIRE_SOCKET             : None

SSH
    shared.in_ssh_connection: false

WSL
    WSL: false

Variables
    SHELL              : Some("/usr/bin/zsh")
    EDITOR             : Some("nvim")
    VISUAL             : Some("nvim")
    YAZI_FILE_ONE      : None
    YAZI_CONFIG_HOME   : None

Text Opener
    default: Some(Opener { run: "${EDITOR:-vi} \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true })
    block  : Some(Opener { run: "VIM_FORK=0 $EDITOR \"$@\"", block: true, orphan: false, desc: "VIM_FORK=0", for_: None, spread: true })

Multiplexers
    TMUX               : false
    tmux version       : 3.4
    ZELLIJ_SESSION_NAME: None
    Zellij version     : No such file or directory (os error 2)

Dependencies
    file             : 5.45
    ueberzugpp       : No such file or directory (os error 2)
    ffmpegthumbnailer: 2.2.3
    magick           : 7.1.1-27
    fzf              : 0.55
    fd               : 10.2.0
    rg               : 14.1.1
    chafa            : 1.14.2
    zoxide           : 0.9.4
    7z               : 24.08
    7zz              : No such file or directory (os error 2)
    jq               : 1.7


--------------------------------------------------
When reporting a bug, please also upload the `yazi.log` log file - only upload the most recent content by time.
You can find it in the "/home/jan/.local/state/yazi" directory.

Did you try the latest nightly build to see if the problem got fixed?

No, and I'll explain why below

Describe the bug

There are various places where Yazi uses the term "ctime" for a timestamp associated with a file, for example in linemodes or when sorting files. However, Yazi incorrectly uses the term to refer a file's "creation time", when the term generally refers to a file's (metadata) change time, that is when the inode changes. The creation time is called names like "btime" or "birthtime".

This is also mentioned in Rust's std::fs::Metadata documentation, which Yazi uses here:
https://doc.rust-lang.org/std/fs/struct.Metadata.html#method.created

The returned value corresponds to the btime field of statx on Linux kernel starting from to 4.11, the birthtime field of stat on other Unix platforms, and the ftCreationTime field on Windows platforms.

This is from Linux's statx(2) man page:

               struct statx_timestamp stx_atime;  /* Last access */
               struct statx_timestamp stx_btime;  /* Creation */
               struct statx_timestamp stx_ctime;  /* Last status change */
               struct statx_timestamp stx_mtime;  /* Last modification */

Also, from ls(1):

       --time=WORD
              select which timestamp used to display or sort; access time (-u):
              atime,  access,  use;  metadata  change time (-c): ctime, status;
              modified time (default): mtime, modification; birth time:  birth,
              creation;

Minimal reproducer

Attempt to show a file's changed time in Yazi and be surprised at the unexpected timestamp

Anything else?

Both the btime and the ctime are useful, so I would suggest changing the code to (internally) use the properly named btime everywhere Yazi explicitly talks about "created time" and add a field btime where it currently uses ctime (like linemodes), and then use the actual ctime for the ctime mentions and add a "changed time" reference in places like file metadata.

[sxyazi]

Please try #1761

[majutsushi]

That was quick, thanks for the comprehensive fix! It seems to work fine, the only comment I have is that it would be nice to have a default linemode and sorting shortcut key for the new ctime.

[sxyazi]

sorting shortcut key for the new ctime

Could you describe your workflow? When would you need to sort files by ctime (file metadata change time) instead of mtime (file content modification time)?

Also, would it be possible or necessary to merge ctime and mtime into a single sorting option, where the latest either of the two is always used as the most recent modification time for sorting?

[majutsushi]

Just recently I had a case where I had renamed some files (changing the ctime), but I wanted to know when I last edited them (the mtime), which was longer ago. So it's definitely useful to be able to have access to both as linemodes.

When it comes to sorting specifically I don't know of a particular usecase off the top of my head, I just think it would be a bit odd to have only partial support for sorting timestamps. But as long as the underlying support is there so that it's possible to define your own sorting shortcut for each timestamp it's not really a big deal, and maybe a combined sorting option would be a good default thing to have.

[sxyazi]

My concern is that if we don't combine them, sorting by ctime will keep a platform-specific feature, which might confuse non-Unix users and I can't think of a real use case for sorting by ctime on its own.

Would you like to file a new issue for this? We can continue the discussion there to prevent it from getting lost.

[majutsushi]

I'm not sure there's a specific thing to create an issue for — I'm happy with the current underlying support for the separate modification times, the default keyboard shortcuts were just a suggestion.

Or did you mean an issue about a combined shortcut? In that case you probably know better how you would want it to behave.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days. ⏳
This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please file a new issue and complete the issue template so we can capture all the details necessary to investigate further.