If you think you found a bug, submit a support ticket with debug info.
Our Help file specifically states the names Amazon use for / call the credentials you need to use (Access Key & Secret Key) via Pro. Nowhere do we mention the Account UserName, etc.
Cloud services notoriously do not store the visible LastModified stamp of a file properly (it generally gets stamped as 'date/time of upload'), with no way to force-set it to match the local file you copied there, meaning backup/sync software can't tell next time if the cloud-side file is the same as 'local' or not. Various services need various modes to work around this, and on S3, files we upload are given special meta-data (which is possible, on S3) to store the LastModified stamp as [same as local file's property].
Naturally, files uploaded by other means do not have this meta-data, hence if you point Pro at them, it has to rely on the only (spurious) date/time info there is, which is 'different' to your local files - thus the proposed upload to remedy that (because that's what you've told it to do - remedy differences). But you can add the missing meta-data to the cloud side by selecting the files it proposes to re-upload, and changing the Action to Use Details From [Source, Left, whatever applies]. Of course, you have to be sure that none of your Source files really are different now to what is stored on the Cloud - because Pro has no way of determining that, and will 'stamp' them regardless, if you tell it to. If you use this (and the cloud-side file is older), the cloud copy will be marked as 'matching' and won't be updated again unless/until the source file changes again
Our Help file specifically states the names Amazon use for / call the credentials you need to use (Access Key & Secret Key) via Pro. Nowhere do we mention the Account UserName, etc.
Cloud services notoriously do not store the visible LastModified stamp of a file properly (it generally gets stamped as 'date/time of upload'), with no way to force-set it to match the local file you copied there, meaning backup/sync software can't tell next time if the cloud-side file is the same as 'local' or not. Various services need various modes to work around this, and on S3, files we upload are given special meta-data (which is possible, on S3) to store the LastModified stamp as [same as local file's property].
Naturally, files uploaded by other means do not have this meta-data, hence if you point Pro at them, it has to rely on the only (spurious) date/time info there is, which is 'different' to your local files - thus the proposed upload to remedy that (because that's what you've told it to do - remedy differences). But you can add the missing meta-data to the cloud side by selecting the files it proposes to re-upload, and changing the Action to Use Details From [Source, Left, whatever applies]. Of course, you have to be sure that none of your Source files really are different now to what is stored on the Cloud - because Pro has no way of determining that, and will 'stamp' them regardless, if you tell it to. If you use this (and the cloud-side file is older), the cloud copy will be marked as 'matching' and won't be updated again unless/until the source file changes again