Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cache_dir not working #1919

Open
3 tasks done
Xygyl opened this issue Nov 18, 2024 · 6 comments
Open
3 tasks done

cache_dir not working #1919

Xygyl opened this issue Nov 18, 2024 · 6 comments
Labels
bug Something isn't working cant reproduce The issue cannot be reproduced as described

Comments

@Xygyl
Copy link

Xygyl commented Nov 18, 2024

What system are you running Yazi on?

Linux X11

What terminal are you running Yazi in?

kitty v0.36.4

yazi --debug output

Yazi
    Version: 0.3.3 (af565fb 2024-11-18)
    Debug  : false
    Triple : x86_64-unknown-linux-gnu (linux-x86_64)
    Rustc  : 1.82.0 (f6e511ee 2024-10-15)

Ya
    Version: 0.3.3 (VERGEN_IDEMPOTENT_OUTPUT 2024-10-09)

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

Adapter
    Adapter.matches: Kgp

Desktop
    XDG_SESSION_TYPE           : Some("tty")
    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("/bin/nu")
    EDITOR          : Some("/usr/bin/hx")
    VISUAL          : None
    YAZI_FILE_ONE   : None
    YAZI_CONFIG_HOME: None
    YAZI_ZOXIDE_OPTS: None
    FZF_DEFAULT_OPTS: None

Text Opener
    default     : Some(Opener { run: "hx \"$@\"", block: true, orphan: false, desc: "hx", for_: None, spread: true })
    block-create: Some(Opener { run: "hx \"$@\"", block: true, orphan: false, desc: "hx", for_: None, spread: true })
    block-rename: Some(Opener { run: "hx \"$@\"", block: true, orphan: false, desc: "hx", for_: None, spread: true })

Multiplexers
    TMUX               : false
    tmux version       : No such file or directory (os error 2)
    tmux build flags   : enable-sixel=Unknown
    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.2
    pdftoppm         : 24.08.0
    magick           : 7.1.1-38
    fzf              : 0.55.0
    fd               : 10.2.0
    fdfind           : No such file or directory (os error 2)
    rg               : 14.1.1
    chafa            : No such file or directory (os error 2)
    zoxide           : 0.9.6
    7z               : No such file or directory (os error 2)
    7zz              : 24.08
    jq               : No such file or directory (os error 2)

Clipboard
    wl-copy/paste: 2.2.1 / 2.2.1
    xclip        : No such file or directory (os error 2)
    xsel         : No such file or directory (os error 2)


--------------------------------------------------

Describe the bug

I have three drives in my system: my root drive, a hard drive, and an ssd. I have set the cache_dir to a directory on my ssd and when I load images on my hard drive they show up in that directory, so I know that it's working correctly. However, when I reboot, the cached images remain but when I load their counterparts on my hard drive it's as if they were never cached.

Minimal reproducer

Due to the nature of this issue, I'm not sure what to put here. I suppose you could reproduce the issue if you have a setup similar to mine: the media being on one drive and the cache_dir on another, with neither of them being the root drive.

Anything else?

No response

Validations

  • I tried the latest nightly build, and the issue is still reproducible
  • I updated the debug information (yazi --debug) input box to the nightly that I tried
  • I can reproduce it after disabling all custom configs/plugins (mv ~/.config/yazi ~/.config/yazi-backup)
@Xygyl Xygyl added the bug Something isn't working label Nov 18, 2024
@sxyazi
Copy link
Owner

sxyazi commented Nov 19, 2024

I can't reproduce it.

Yazi uses file's path and mtime as the unique id for caching:

let hex = {
let mut digest = Md5::new_with_prefix(file.url.as_os_str().as_encoded_bytes());
digest.update(format!("//{:?}//{}", file.cha.mtime, t.raw_get("skip").unwrap_or(0)));
format!("{:x}", digest.finalize())
};
Some(Url::cast(lua, PREVIEW.cache_dir.join(hex))).transpose()

Are you sure the mtime of your files hasn't changed?

@sxyazi sxyazi added cant reproduce The issue cannot be reproduced as described waiting on op Waiting for more information from the original poster labels Nov 19, 2024
@Xygyl
Copy link
Author

Xygyl commented Nov 23, 2024

Yes. The files haven't been edited since they've been written to the disk. I have

@Xygyl Xygyl closed this as not planned Won't fix, can't repro, duplicate, stale Nov 23, 2024
@github-actions github-actions bot removed the waiting on op Waiting for more information from the original poster label Nov 23, 2024
@Xygyl
Copy link
Author

Xygyl commented Nov 23, 2024

oops, didn't mean to close it. sorry.

@Xygyl Xygyl reopened this Nov 23, 2024
@Xygyl
Copy link
Author

Xygyl commented Nov 23, 2024

I checked the mtime, checked the name of the files in my cache_dir, rebooted to see if the problem persisted (it did), deleted the files in my cache_dir, rebooted, recached the images (same names), rebooted, and the problem persisted. If you have any ideas or want anything from me then I'll be happy to provide.

@sxyazi
Copy link
Owner

sxyazi commented Nov 23, 2024

Is it only happening with images? Does the issue also occur with videos or PDFs? Does it happen on a specific drive or all drives? Is that drive an external one? If it is, Windows seems to rename them based on the order they’re connected (D, E, F, etc.), which could be causing the filenames to keep changing.

@sxyazi sxyazi added the waiting on op Waiting for more information from the original poster label Nov 23, 2024
@Xygyl
Copy link
Author

Xygyl commented Nov 23, 2024

I've only tested it with images and videos and it happens with all of them. It happens on every drive. All drives are internal. I'm running gentoo linux.

@github-actions github-actions bot removed the waiting on op Waiting for more information from the original poster label Nov 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working cant reproduce The issue cannot be reproduced as described
Projects
None yet
Development

No branches or pull requests

2 participants