AmazeFileManager icon indicating copy to clipboard operation
AmazeFileManager copied to clipboard

Timestamps not kept when moving

Open cousteaulecommandant opened this issue 7 years ago • 9 comments

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.

cousteaulecommandant avatar Dec 27 '17 16:12 cousteaulecommandant

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.

EmmanuelMess avatar Dec 28 '17 01:12 EmmanuelMess

For a less technical explanation see here.

EmmanuelMess avatar Dec 28 '17 20:12 EmmanuelMess

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 avatar Dec 28 '17 21:12 cousteaulecommandant

@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.

VishalNehra avatar Dec 28 '17 21:12 VishalNehra

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.

EmmanuelMess avatar Dec 28 '17 23:12 EmmanuelMess

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.

mirh avatar May 25 '18 23:05 mirh

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:

th23x avatar May 05 '24 08:05 th23x

this seems to be a bug in File#setLastModified (see this, this & this). looking for workarounds...

VishnuSanal avatar May 07 '24 15:05 VishnuSanal

this seems to be a bug in File#setLastModified (see this, this & this). looking for workarounds...

update: nvm, that works fine, t'was my mistake! btw, added a fallback option too now that we've stumbled upon this. :)

VishnuSanal avatar May 07 '24 16:05 VishnuSanal