Created attachment 172534 [details] print for date columns are with wrong data all file data columns available in dolphin are wrong, ok, last accessed not happens when files are transferred with KDE the "new" file get set to transfer date in all date headers, that is wrong ... setting creation time and modified time to a new value is wrong because the wasn't really modified, changing last access time is ok happens also that the real creation time is not available in Dolphin but is in the file's meta data, as well as photographed time is in the file, but the column in dolphin is empty for any kind of image file, I have to compare TIF, png, jpg, dng and arw IMO that is a very severe problem, at least for whom works with lots of images, because the files CAN NOT listed in the correct order and makes it very hard to find what you look for please look at the attached prints Gwenview related is, when you then open a file to view, in order to review (browse) a sequence, you need to set a new sort order in Gwenview, if not random picture sort happens and that is a mess overall that is not a new problem, last time I related it, somebody argued with me that my info is wrong and on his cellphone it is all ok ... I hope this doesn't happen again because who's wrong is who coded it wrong and should e corrected Linux: Neon, Mint, Arch all up to date KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.72
Created attachment 172535 [details] Attachments print for date columns are with wrong data
please also pay attention to the sort order on the print, select is "created, newest first" and that is not what is showing
When you transferred the files, did you use Copy and Paste (i.e. cp) or Cut and Paste (i.e. mv)? Dolphin seems to behave in the same way as the command line default behavior in respect of timestamps, which seems reasonable to me.
this happens when using dolphin to copy or move the files to the local hd this also happens when transferring with kde connect since the copied file is identical to its origin, the creation date should not modified, there is no change in the file, just the last access could be modified by such an operation anyway, failing file sort is always wrong
Closing since this is just how the standard file timestamps (atime, mtime, ctime..) work on linux
you haven't understood the real problem