aws-cli (after a quick perusal of their source code) uses the LastModified
value (set by S3 to be the time the upload of the object occurred) on
objects in S3, which is obtainable from the <ListBucket> XML, without doing
a HEAD call. They then go on to calculate the difference between
LastModified and stat.mtime(), accounting for time zone differences.
local files use stat.mtime.
aws-cli then proceeds to compare the two values; if LastModified is newer
than stat.mtime, syncing local->remote is skipped (the remote is newer than
local); likewise on download, if LastModified is older than the local file,
it too is skipped.
Neither tool sets LastModified = stat.mtime on upload (nor can they).
s3cmd gets around this by setting stat.mtime into the file's metadata when
--preserve (the default) is used, but then would have to use a HEAD or GET
call to get it back. s3cmd does update the local on-disk mtime and atime
when downloading (GETting), because we get the header back, and that's free
then. Likewise, aws-cli sets both mtime and atime = LastModified on
download.
So aside from aws-cli skipping over newer files in destination, I think
their behavior is identical.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
S3tools-general mailing list
S3tools-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/s3tools-general
