[dolphin] [Bug 430819] Creation time (crtime/btime) is not displayed for devices with these file systems FAT, FAT32, exFAT and NTFS

[Méven Car]

https://bugs.kde.org/show_bug.cgi?id=430819

Méven Car <meven29 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |meven29 at gmail.com
             Status|REOPENED                    |CONFIRMED

--- Comment #8 from Méven Car <meven29 at gmail.com> ---
(In reply to filefolderneon from comment #7)

> Here is a screenshot and I have started KDE neon on a bootable Live USB (FAT32) created with rufus.

> You see in the screentshot that I tried a .txt file with the command "stat" and it does not show creation time (Birth time). You also > see that I am using Dolphin in Details view mode and "Created" is added to the column. In the column under "Created" there is no > entry and when I open the .txt file via Properties the "Created" entry is completely missing.

Then the type of the mounted filesystem is not FAT32 but squashfs itself
mounted from the FAT32 partition.

> Created attachment 134517 [details]
> External USB flash drive (FAT32) connected to the computer
> 
> KDE neon is already installed on the computer. Here I have mounted an
> external USB flash drive (FAT32) and the creation time is not displayed.
> 
> Additional information:
> Same problem with FAT, exFAT and NTFS external USB flash drive.
> 
> If I do the same here with Windows 10, it works, it shows the creation time
> on the external USB flash drive.

https://gitlab.gnome.org/GNOME/nautilus/-/issues/1734 is a good reference.
or
https://www.reddit.com/r/linuxquestions/comments/fycd7q/date_created_on_linux/

tldr; Linux usually has 4 timestamps, the third one being "metadata change
time" and Window has three the third being "creation time".
And statx does not differentiate the field depending on the filesystem, and the
filesystem implementation does not expose this either or at least not
correctly.

We could handle it at our end though, but currently our file access
implementation does not know the fs type it operates on.
But really we would want an upstream fix in the Kernel.

-- 
You are receiving this mail because:
You are on the CC list for the bug.