I don't get it: Keeping timestamp is set to on by default in DO-settings. I have a move-command which sets actual timestamp when moving ("Copy MOVE COPYTIME=no"). But how to keep the creation time? It makes no difference if "COPYCREATIONTIME" is set to on or off. I just want to be able to sort by last moved files without losing original creation time.
Are you moving between devices/partitions, or on the same one?
What is the actual command that you are trying?
The actual command is above mentioned in brackets and moving is between two different HDD's.
For example: I've created a document and want to keep creationdate (when doc was originally created), but also be able to sort newly moved (or copied) files. Under file-properties all date-based-entries are indentical when using this command.
So you're not using COPYCREATIONTIME=yes in the command?
For testing I did, but there was no difference (btw it should be activated by DO-settings as keeping timestamp is on). Every timestamp-entry will be changed.
Any news? BTW related question, if there is a command to turn on/off timestamp-setting within prefs in a button, so that it can be used for all copy-operations?
...the help manual associates that Prefs option (Copy Attributes->Preserve the timestamps of copied files) with only the COPYTIME raw Copy command argument... which in turn is described as only affecting the "last modified and last accessed time" attr info. So, you wouldn't expect that Prefs option to have anything to do with CREATIONTIME one way or another.
From a quick test - I saw that even copying a file from my laptop to a NAS share (obviously a different HDD and partition than the source laptop) preserved the creation date as expected. But then I read your comments a bit more closely... and I did another test with what I "think" you might have tried re: the use of the COPYCREATIONTIME == Copy COPYTIME=no COPYCREATIONTIME=yes.
That seems to result in what you're seeing - i.e., the COPYTIME=no argument properly prevents preservation of the last accessed and modified timestamps... but it also seems to clobber the use of COPYCREATIONTIME=yes. If you get rid of the COPYTIME=no arg, you should see the COPYCREATIONTIME arg work properly. Smells like a bug?
Yes, if copytime is used as no, creationtime will be lost and set to actual date/time.
...as you mentioned NAS it seems to work with EXT3- but not on NTFS-partitions.
Hmmm... I'd have thought you'd see the NAS results you mentioned the other way around if ANYthing (i.e. work ok on NTFS, but wrong on EXT3). But if I had to guess I'd say your mixed NAS results more likely have something to do with a NAS OS compatibility snafu rather than it simply being due to the partition type differences. Opus itself certainly wouldn't have any clue about the backend NAS filesystem type - it' should be "just a CIFS share" as far as anything running on the client PC is concerned.
No, you missunderstand... problem occurs not on NAS, it occurs when copying between internal 2 HDD's with NTFS. As it works for you on NAS, I assumed that it seems to work on EXT3-partitions.
Ah, then we BOTH misunderstood each other I think. NAS or HDD makes no difference for what seems to be causing the apparent bug... which is that combining COPYTIME=no with COPYCREATIONTIME=yes seems to cause the CREATIONTIME arg to be overridden. Combining those two args ALSO fails on NAS - just the same as on local NTFS, and regardless of the backend NAS filesystem type.
In any case - bug report submitted 
.
Ok 
We'll change the next version so that COPYCREATIONTIME overrides COPYTIME and COPYDIRDATES instead of vice versa.
I'm not sure it was a bug, but the reverse behaviour makes more sense so we've changed it.
Out of curiosity - why would either option "override" the other... at least between COPYTIME and CREATIONTIME, they affect totally separate attr info. I'd think the most sensible thing would be for them to independently affect the separate fields they're each meant to affect, no?
COPYTIME affects all timestamps. Always has done AFAIK.
Confusing in English, so which cmd will keep copycreationtime and set copytime to new in future then?
Copy COPYTIME=no COPYDIRDATES=no COPYCREATIONTIME=yes
Ok, as always thanks Leo.