rsync? Or compress it, that should preserve dates and times.

Last edited by damarrin on 28 May 2021 at 7:08 pm UTC

Good old `cp -a` (or --archive) should do the trick. Check the man page for more info.

Quoting: tuubiGood old `cp -a` (or --archive) should do the trick. Check the man page for more info.

That command keep the modification date, but not the creation date..

I need the copy to be a perfect clon.

Quoting: Comandante Ñoñardo

Quoting: tuubiGood old `cp -a` (or --archive) should do the trick. Check the man page for more info.

That command keep the modification date, but not the creation date..

I need the copy to be a perfect clon.

Sorry, I don't know a way around that beyond cloning the whole file system. Archiving, rsyncing or whatever won't help you there. The file system updates the ctime whenever an inode is changed in any way, and as far as I know the Linux kernel doesn't have a mechanism for overriding this behaviour.

I don't think Lutris cares about ctimes though, so I guess you have some other reason to worry about it.

Use cp -p

From manual page:
-p implicts --preserve=mode,ownership,timestamps

It's my translation to English, so sorry it was wrong. I have localized manuals.

Of course,

--preserve=timestamps should also do the trick.

Also
cp -pP

It will copy symbolic links content instead location it points to. The -P do the trick.

From manual
-P, --no-dereference
never travel through symbolic links in source

I suggested `cp -a` earlier, and it already implies --preserve=all. But there's no way to make cp preserve the ctime timestamp.

Quoting: tuubiI suggested `cp -a` earlier, and it already implies --preserve=all. But there's no way to make cp preserve the ctime timestamp.

And If I play with the system time before making the copy?

What is more fast? The use of cp or Rsync?

I think, for this case, rsync and cp would be about the same. Rsync's advantages are that it can compress over a network and that it can "update", skipping unchanged files that already exist in the destination directory.

Unless your doing one of those things, I find them to be about the same in terms of speed.

Quoting: Comandante ÑoñardoAnd If I play with the system time before making the copy?

That's a clever idea! Although, wouldn't you have to alter the system time for every file just before you copy it to ensure every file has the same time as the old? I wonder if that's is scriptable in bash?

I can't remember what is called exsctly, but I think you might want to consider disabling the NTP deamon/service thing so the system doesn't automatically "fix" and resync to the correct time in the middle of you work. Or take the computer in question off the internet. Prolly easier to disconnect.

Quoting: denyasis

Quoting: Comandante ÑoñardoAnd If I play with the system time before making the copy?

That's a clever idea! Although, wouldn't you have to alter the system time for every file just before you copy it to ensure every file has the same time as the old? I wonder if that's is scriptable in bash?

Hah! I assume you would have to do exactly that. And of course it's scriptable. This is Linux! :grin:

The script shouldn't be too complicated either. I'd guess it would just iterate over the files, grab the file ctime (inode change time, not to be confused with data modification time) with something like `stat -L --printf='%Z' [FILE]`, set the system time with `date +%s -s @[TIMESTAMP]`, then copy the file over. Rinse and repeat. This is probably a bit slower than a straight copy, but you don't have to copy the whole folder in one go.

The resulting timestamps will differ just slightly from the originals, because there'll be a tiny delay between you setting the time and the subsequent copy operation creating the target file. It's also possible that this does not even work. I haven't tested any of the above, and I'm not going to.

Stat might also be able to return the actual file "birth time" if your coreutils package is recent enough and you use a file system that stores it. You can grab that into a variable with `stat -L --printf='%W'`. Most Linux software doesn't read or make any use of this timestamp though.

Note that messing with your system time will mess up timestamps for any processes writing logs or files at the same time, so you might want to use a live USB so your actual system is unaffected. Or something like that.

If you end up actually doing this, you've certainly got my respect for the dedication. I still don't see the point, but who cares. Tinkering is fun.

Last edited by tuubi on 30 May 2021 at 1:24 pm UTC