I’m pretty well versed in Kodi, having argued with this ‘feature’ before.
The ‘date added’ field in kodi can be set to use any of the following items via the advancedsettings.xml file:
modified time of the file (not creation time, although it uses ctime in the event that mtime is invalid, see below note on ctime),
- Date at which the item was scanned into the library using the advancedsettings.xml file.
- Newest date between ctime and mtime
In linux, the ctime flag of a file is the time at which the inode was last updated (change time, not created time), which in the case of a copy would be NOW.
It will NOT reflect the created time on the NTFS FS, it will (initially) reflect the time at which the file was created on the linux system. I say initially, as it will update to the latest modification or property change time of the file.
The difference between ctime and mtime is primarily that ctime will include permission, ownership and attribute changes, not just content changes.
Note that copy, rsync and tar are all capable of preserving modified timestamps.
There is another flag in some *nix filesystems, called btime (birth time), however this isn’t supported by some filesystems (and most tools) so it can safely be ignored.
With regards to your copy, I would advise against rsync for this situation, overheads on checksumming etc will likely bottleneck on local transfers.
cp will be quite capable of handling what you’re trying to do, however I think a local tarpipe will probably get a better throughput, but without knowing exactly how your content is distributed on your source FS, I can’t be too sure.
The proviso here is that neither a tarpipe or standard copy will have a reliable recovery technique if the copy dies part way through. A tarpipe can be managed for recovery of a broken copy using exclude lists, but this would be tiresome.
A cp can sort of recover, with the flags (from the man page):
do not overwrite an existing file (overrides a previous -i option)
copy only when the SOURCE file is newer than the destination file or when the destination file is missing
Note however that if you used either of these flags, if the last file was partially copied (which is quite likely), that broken file would not be overwritten with the good file on the source.
rsync is the safest option out of those presented, but also likely to be the slowest.
I hope I’ve provided you the necessary information to make an informed decision to suit your particular needs.