When synchronizing material between S3 buckets, or when synchronizing to or from a local filesystem, the files seem to wind up timestamped with the time of the transfer, not the timestamp of the transferred file. Timestamps should be preserved when syncing _to_ S3, and when syncing S3 folders to S3 folders. Otherwise, content that is synced form one S3 bucket to another will have confusing tmestamps, and switching from one upstream source bucket to another for local directory syncs will cause unnecessary updates with mismatched timestamps.
If this cannot be done, if the S3 objects do not support resetting the timestamps on them after transfer, then the command line argument should be rejected as invalid if the target of the sync is an S3 bucket.
The --exact-timestamps
is not for setting the LastModifiedTime of the S3 objects. This is not possible to do via the S3 api. The docs for this option give more info:
--exact-timestamps (boolean) When syncing from S3 to local, same-sized items will be ignored only when the timestamps match exactly. The default behavior is to ignore same-sized items unless the local version is newer than the S3 version.
In other words, this is only used to control what files are synced, not to sync the timestamps. Happy to discuss more, let me know if I've missed anything.
That needs to be clear in the documentation. It's not. For everyone who's every used "rsync" or other synchroniztion tools, the lack of this ability causes very real confusion.
The ability to set local timestampes for downloaded objects, based on the AWS timestamp, would also be invaluable even if it can't be set the other way.
Most helpful comment
That needs to be clear in the documentation. It's not. For everyone who's every used "rsync" or other synchroniztion tools, the lack of this ability causes very real confusion.
The ability to set local timestampes for downloaded objects, based on the AWS timestamp, would also be invaluable even if it can't be set the other way.