AmazeFileManager
                                
                                
                                
                                    AmazeFileManager copied to clipboard
                            
                            
                            
                        Timestamps not kept when moving
I just used Amaze to move all my photos from internal storage to the SD card, and learned the hard way that Amaze does not keep timestamps when moving files. Since my default gallery app isn't smart enough to use EXIF data to sort images, this means that one year of photos and videos got shuffled. (Good thing I know Perl; I eventually managed to make a script that sets the timestamp of files based on their name, so at least I fixed the mess I made.)
Apparently when Amaze "moves" files, it just copies them (without preserving timestamps) and then deletes the original, so the solution might be as simple as setting the copy to preserve timestamps, at least when moving files.
Timestamps in UNIX are not like in Windows, there's no creation date saved on the file (that is, on the inode).
st_atime This is the file's last access timestamp. st_mtime This is the file's last modification timestamp. st_ctime This is the file's last status change timestamp.
Source: stat(2) man page.
For a less technical explanation see here.
There is indeed no creation timestamp, but there is a modification timestamp, which is the important one—the one my gallery application relies on (as do most applications featuring a "sort by time" option) and the one Amaze didn't keep.  (It can be set with the touch -mt command which is what I eventually did, or preserved when copying with cp -p which is what I think Amaze should do)
PS: with "most applications" I was thinking on desktop file browsers such as Nautilus, or command line applications like ls -t
@cousteaulecommandant there's no way to preserve them when you move to a mountable storage such as SD Card. If, however, you move those files within internal storage then they will be preserved. Edit : my bad, there are ways to preserve, but implementing them is outside the scope of a file manager.
Here's the solution:
int targetfile = open(target_file_path, O_WRONLY|O_CREAT|(no_clobber ? O_EXCL : 0), 0600);
struct timespec times[] = { source_stat->st_atim, source_stat->st_mtim, };
futimens(targetfile, times);
Source: How difficult is it to preserve metadata when moving a file? by Richard Maw (extract). This is not trivial, but can be implemented. Related: #843.
Edit : my bad, there are ways to preserve, but implementing them is outside the scope of a file manager.
Why? On a desktop it would be totally expected behavior.
Hi and first of all thanks for this great file manager!
Would like to come back to this issue from a few years ago, as I have to admit, am facing the same challenge. And additionally I don't see the topic "outside the scope of a file manager" ( @VishalNehra ) as many others eg the stock Samsung file manager as well as some others do preserve the "last changed" timestamp also upon a move to the SD card.
Would appreciate, if this could be looked into again - and potentially also changed (or at least be a switchable option) - as it at least for me is the "breaking point" why I would currently not use the Amaze file manager, sorry...
-- Edit / Addition: --
Just looking into another open source file manager by Fossify (https://github.com/FossifyOrg/File-Manager/) I found the following option in the settings for exactly this expected behaviour: