Nemo loses file dates when moving data to another volume

[Menard]

Hello

I don't know exactly how and when, but it is a major issue for me
When I download a file on my home (Ext4) I get 2 dates, "modification date" date of the file (may be old) and "creation date" is today (date when the file was downloaded) and if I move the file then, only the modification date is kept, but I don't care because what is important for me is the creation date

But you must know that the issue was different before that, a common known issue or bug was that moving a file to another volume was replacing the dates by the date of the moving .. so you had a fix for that, it was to put the files in a folder, now it seems that it was changed but it is worse now
This exists also on Windows

[mikeflan]

Try this method and tell us if it works:
viewtopic.php?p=965612#p965612

[Menard]

Try this method and tell us if it works:
viewtopic.php?p=965612#p965612

I don't use the command line exception for very simple tasks
Thanks though

[Menard]

I made further investigations

So whatever the method, when moving files with Nemo, from the /home (Ext4) to an NTFS volume on another hard disk, Mint loses the creation date of some files without knowing for the moment , why ....
This creation date is replaced by "Unknown"

but I see this :
I moved the whole "Téléchargements" folder like this and all the files lost their creation date

but doing it file by file, only the half lost it .... totally weird


question : which further tests doing ?
one of the problem is that a file is able to be tested only one time ...

From a logical point of view, when we move a file we expect it to be unchanged, all unchanged

[Menard]

AND i'm not interested in the command line

[Moonstone Man]

Mint loses the creation date of some files ...

No, Mint does not lose the creation date, or the time. NTFS loses it.

AND i'm not interested in the command line

That's ok. You get to live with it.

[Menard]

Mint loses the creation date of some files ...

No, Mint does not lose the creation date, or the time. NTFS loses it.

AND i'm not interested in the command line

That's ok. You get to live with it.

The main selling argument of Mint is to say : ok Linux is for geeks but Mint is like Windows so not for geeks ...

You are wrong because it happens when moving to another Ext4 volume as well

It doesn't explain neither why this is not constant

What makes this particularly huge, awful, is that when it's done, it is done forever... you will never have back your archives with all dates correct

In my /home/user I see this : 50% of the files are at risk to lose the good date because they kept a date far older than the real, if so i ll lose all my system to find back the good file because it mainly based of indexation by dates

I add this : from ext4 to ext4 you keep the original date (that I don't care of it) and the good date is replaced by the moving date (I don't care neither) and so the only date that is useful to organize your data, is lost
In french we call this "loi de l'emmerdement maximum" i don't know if it is translatable

[Moonstone Man]

In french we call this "loi de l'emmerdement maximum" i don't know if it is translatable

Sure it is. The law of maximum pain in the^h^h^h irritating inconvenience.... In English it's similar to Murphy's law, anything that can go wrong will go wrong.

[Menard]

Another information now :

I installed and tested Grsync and it gives nothing more, worse, it makes you believe that it will keep your important date but no ... because you can tick the box called "Keep the date" but after moving the data, the result is exactly what is done by Nemo by default

I tested zip compression too, but with no success

I am searching why sometimes, generally not when testing, it works, it is allways when the files are moved without a folder, but it works not for all files

[Menard]

Try this method and tell us if it works:
viewtopic.php?p=965612#p965612

I tested it and no it doesn't work

Code: Select all

cp -p /home/u3/Racine/202106/Test /mnt/924CFEB44CFE9269/Test

with or without sudo, because some people say it is a problem with rights, ownership differences between files and volumes
I notice that files owner, from "Me" becomes "Root" in the process

The only "solution" that really works, is to dispatch the data by monthly, weekly, daily folders ...

here https://askubuntu.com/questions/261553/ ... -directory someone says we must use the uuid so i am in this case ... and it doesn't work

[Hoser Rob]

... Mint loses the creation date of some files without knowing for the moment , why ....

AFAIK the issue is that the ext4 file system used by Mint supports file creation date but the Linux kernel APIs don't. So it's not just a Mint issue, the Linux kernel is a separate project used by all GNU/Linux distros. And it sounds as stupid to me as it likely does to you.

I've not had a problem with this myself but I've read stuff on it and I never saw a solution that didn't use the terminal. There may be one though.

[Menard]

... Mint loses the creation date of some files without knowing for the moment , why ....

AFAIK the issue is that the ext4 file system used by Mint supports file creation date but the Linux kernel APIs don't. So it's not just a Mint issue, the Linux kernel is a separate project used by all GNU/Linux distros. And it sounds as stupid to me as it likely does to you.

I've not had a problem with this myself but I've read stuff on it and I never saw a solution that didn't use the terminal. There may be one though.

I tried all the solutions with a terminal using cp or mv and none works

That's what I have just read from a person who seems to know :
"Some implementations fix this (like GNU coreutils mv 8.29), and others don't"

https://unix.stackexchange.com/question ... 897#657897

With Windows I remember having had sometimes this too but I hardly remember how and when but I found some recent discussions like this about Windows 10

[revmacian]

I have to ask.. how much do you want this issue resolved?

Try this method and tell us if it works:
viewtopic.php?p=965612#p965612

I don't use the command line exception for very simple tasks
Thanks though

So, you want this issue resolved.. but your desire is not strong enough to research all possible avenues to a resolution? What if the command line could offer a quick solution to your issue? Are you not willing to research that avenue and are willing to live with your issue in order to avoid learning something new?

Do yourself a favor and learn the command line, it's more powerful and offers more control than any GUI I've ever seen in my 20+ years on Linux. I'm not saying the command line will offer a solution to the issue, but it will assess a possibility. And, assessing all possibilities is part of the act of research.

Just something to think about in the future.

[Menard]

Perhaps I ve found today a partial solution :

When selecting files by shift+click shift+click and then cut paste, on 24 files, all dates were kept ...
When moving a whole folder, all inside dates are lost

[Menard]

Just this : it is not my work !
but
As I am kind, I add : computers, the purpose was to help us, not the contrary ...

But I made an exception because I was particularly angry and then I lost all a sunday for nothing as we are in summer and i could go to the beach or else and i'd prefer this, we had severe covid restrictions

[mikeflan]

@Menard
Thanks for pointing this out. And thank you Rob for the kernel info related to this.
I really only care about the modified date, and thankfully that appears to be good. If the creation date option is kept, it should be fixed. I hope it does get fixed.

[revmacian]

.. As I am kind, I add : computers, the purpose was to help us, not the contrary ...

Yes, you are correct, the purpose of computers is to help us.. and part of that help is to help us grow, learn and improve. Part of the growing and improving process is to learn that your comfort zone is not meant to be a residence. So, computers do help us.. but it depends on your definition of "help".

[Menard]

It is unbelievable, moving some files instead of moving some folders, that work but partially ...

First I moved 44 files with no failure, and after this, for another folder I had 50% failures on 12 files, and ater this I had 6 failures on 42 files... and then 119 failures on 451 files, and I see that these failures appear by groups, more statistically than theorically possible ... there is a major point there ... I ll made a statistical study of these groups ...

This is the distribution of the lost dates when you display the 451 files by date : 9 13 1 1 2 2 1 2 3 1 5 1 1 1 1 1 8 1 5 8 1 3 3 1 1 6 1 8 6 1 2 4 1 7 1 1 5
it has to be read like this : 9 consécutive files with loss, 13 consecutive files with loss etc

so if someone want to make a study .... it is not random at first glance

[Menard]

In conclusion, what we learn about this issue, bug, is :

- moving files from ext4 volume to another ext4 volume using folders or not : you are sure to lose the creation date

- moving files from ext4 volume to ntfs volume using folders : it is the same result

- moving files from ext4 volume to ntfs volume not using folders : you lose a small part of the creation dates without knowing why (we are stil searching)

Nemo don't deal with this more than the commands as mv or cp

None of the solution proposed on the internet, works ...
We can wonder why so many people appear to propose solutions that don't work but pretending they work ... mystery

[MAlfare]

When I download a file on my home (Ext4) I get 2 dates, "modification date" date of the file (may be old) and "creation date" is today (date when the file was downloaded) and if I move the file then, only the modification date is kept, but I don't care because what is important for me is the creation date

Ever thought of the fact, that the copied/moved file is created in the target, at the time it is copied/moved ?