Preserve timestamp

[cdtut]

Please describe the problem you're trying to solve

y and x changes file attribute like timestamp after p.

Would you be willing to contribute this feature?

• Yes, I'll give it a shot

Describe the solution you'd like

All actions in yazi should always keep all original attribute.

Additional context

No response

[sxyazi]

All actions in yazi should always keep all original attribute.

‘All actions’ is vague to me. Please list all the operations you want to keep track of.

And should it be the default behavior? Should the previous behavior be preserved (e.g., by adding a different configuration option)? It would be very useful if you could provide some implementations of other file managers for me to use as a reference.

[cdtut]

Copy file should be like cp --preserve=all. Move should be like mv which doesn't change anything on file. Other file manager like ranger do that.

It should be default. Previous behavior should not be there, you would never expect moving file to change anything.

[sxyazi]

Thanks for the explanation, but why should copy be like cp --preserve=all instead of just cp, if move is like mv?

I just tested locally, and the default behavior of cp (without --preserve=all) does not preserve timestamps. Why should we preserve them?

[cdtut]

Copy in interactive file manager should be considered like clone or mirror where you expect everything to be identical to source files. Other file manager do it like that. I tested in ranger.

It is also safer because some things depend on modified times on files and file attributes.

[sxyazi]

Sounds good to me.

Does anyone want to give it a try? copy_with_progress should be the only place that needs to be changed:

yazi/yazi-shared/src/fs/fns.rs

Line 37 in e7dc971

pub fn copy_with_progress(from: &Path, to: &Path) -> mpsc::Receiver<Result<u64, io::Error>> {

[alexandruoprinca]

I cannot seem reproduce the issue on MacOS running ARM.
I ran the app locally both in debug and release mode (not that it would matter for this particular scenario)
I tried to copy the project README and rustfmt. For the rustfmt i also cut it and pasted it again
This is the output after a ls:
user@192-168-0-0 yazi % date
Wed Apr 10 19:19:06 EEST 2024
user@192-168-0-0 yazi % ls -al
total 264
drwxr-xr-x 32 user staff 1024 Apr 10 19:15 .
drwxr-xr-x@ 41 user staff 1312 Apr 10 19:13 ..
.... project files....
-rw-r--r-- 1 user staff 4719 Apr 10 11:09 README.md
-rw-r--r-- 1 user staff 4719 Apr 10 11:09 README_1.md
-rw-r--r-- 1 user staff 1154 Apr 10 11:09 rustfmt.toml
-rw-r--r-- 1 user staff 1154 Apr 10 11:09 rustfmt_1_1.toml

[sxyazi]

Hi, I tested it in my Linux VM, and it did change the file's timestamp:

-rw-r--r--  1 ika ika  1555 Dec 27 17:07 flake.nix
-rw-r--r--  1 ika ika  1555 Apr 11 00:54 flake_1.nix

I think this should be the different behavior exhibited by Rust's std::fs::copy() on different platforms.

[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 open a new issue and complete the issue template so we can capture all the details necessary to investigate further.