Aws-cli: Sinkronisasi AWS S3 tidak menyinkronkan semua file

Anda mungkin dapat menggunakan --exact-timestamps untuk mengatasi hal ini, meskipun hal itu dapat mengakibatkan unggahan berlebih jika Anda mengunggah.

Untuk membantu mereproduksi, bisakah Anda memberi saya beberapa informasi tentang salah satu file yang tidak disinkronkan?

• Berapa ukuran file yang tepat secara lokal?
• Berapa ukuran file yang tepat di S3?
• Apa waktu terakhir yang dimodifikasi secara lokal?
• Apa waktu modifikasi terakhir di S3?
• Apakah file lokal adalah symlink/di belakang symlink?

Contoh perintah dijalankan
aws s3 sync s3://bucket/ /var/www/folder/ --delete

Beberapa file hilang
Ukuran lokal yang tepat: 2625
Tepat s3: 2625
Cap waktu lokal yang tepat: 06-Jan-2017 9:32:31
Cap waktu yang tepat s3: 20-Jun-2017 10:14:57
file normal di S3 dan lokal

Ada beberapa kasus seperti itu dalam daftar sekitar 50.000 file. Namun semua yang hilang sinkron adalah berbagai waktu pada 20 Juni 2017.

Menggunakan --exact-timestamps menunjukkan lebih banyak file untuk diunduh meskipun isinya persis sama. Namun mereka masih kehilangan yang dalam contoh di atas.

masalah yang sama di sini.
aws s3 sync dist/ s3://bucket --delete tidak mengunggah s3://bucket/index.html dengan dist/index.html

dist/index.html dan s3://bucket/index.html memiliki ukuran file yang sama, tetapi waktu modifikasinya berbeda.

sebenarnya, beberapa kali awscli mengunggah file, tetapi beberapa kali tidak

Sama di sini, --exact-timestamps tidak membantu - index.html tidak ditimpa.

Kami mengalami masalah ini dengan baik hari ini/minggu lalu. Sekali lagi index.html adalah ukuran file yang sama, tetapi isi dan waktu modifikasinya berbeda.

Adakah yang mengetahui solusi untuk ini?

Saya baru saja mengalami ini. Masalah yang sama seperti yang dilaporkan oleh @icymind dan @samdammers : isi file index.html saya (lokal) telah berubah, tetapi ukuran filenya sama dengan salinan sebelumnya di S3. Perintah {{aws s3 sync}} tidak mengunggahnya. "Solusi" saya adalah menghapus index.html dari S3, dan kemudian menjalankan sinkronisasi lagi (yang kemudian mengunggahnya seolah-olah itu adalah file baru, saya kira).

Server: EC2 linux
Versi: aws-cli/1.16.108 Python/2.7.15 Linux/4.9.62-21.56.amzn1.x86_64 botocore/1.12.98

Setelah aws s3 sync menjalankan lebih dari 270T data, saya kehilangan beberapa GB file. Sinkronisasi tidak menyalin file dengan karakter khusus sama sekali.

Contoh file /data/company/storage/projects/1013815/3.Company Estimates/B. Estimates

Harus menggunakan cp -R -n

masalah yang sama di sini file xml dengan ukuran yang sama tetapi cap waktu yang berbeda tidak disinkronkan dengan benar

Saya dapat mereproduksi masalah ini

bug.tar.gz
unduh file tar terlampir dan kemudian

tar -zxvf bug.tar.gz
aws s3 sync a/ s3://<some-bucket-name>/<some_dir>/ --delete
aws s3 sync b/ s3://<some-bucket-name>/<some_dir>/ --delete

Anda akan melihat bahwa meskipun repomd.xml di direktori a dan b berbeda dalam konten dan cap waktu
mencoba menyinkronkan b tidak melakukan apa-apa

Diuji pada
aws-cli/1.16.88 Python/2.7.15 Darwin/16.7.0 botocore/1.12.78
aws-cli/1.16.109 Python/2.7.5 Linux/3.10.0-693.17.1.el7.x86_64 botocore/1.12.99

saya melihat masalah yang sama. mencoba menyinkronkan direktori file dari s3 tempat satu file diperbarui ke direktori lokal. file itu tidak diperbarui di direktori lokal

Saya melihat ini juga. Dalam kasus saya ini adalah aplikasi reaksi dengan index.html yang merujuk ke file .js yang dihasilkan. Saya menyinkronkannya dengan opsi --delete untuk menghapus file lama yang tidak lagi dirujuk. Index.html terkadang tidak diunggah, menghasilkan index.html lama yang menunjuk ke file .js yang sudah tidak ada lagi.

Karenanya situs web saya berhenti berfungsi !!!

Saat ini saya tidak mengerti mengapa ini terjadi.

Apakah ada yang punya ide atau solusi?

Kami memiliki masalah yang sama, tetapi baru saja menemukan solusi. Saya tahu, ini bukan cara terbaik, tetapi berhasil:

aws s3 cp s3://SRC s3://DEST ...
aws s3 sync s3://SRC s3://DEST ... --delete

Tampaknya bagi kami, salinan berfungsi dengan baik, jadi pertama-tama kami menyalin setelah itu kami menggunakan perintah sinkronisasi untuk menghapus file, yang tidak lagi ada.
Berharap bahwa masalah akan diperbaiki secepatnya.

Saya menambahkan --exact-timestamps ke saluran pipa saya dan masalah tidak muncul lagi. Tapi, itu terputus-putus di tempat pertama jadi saya tidak yakin itu memperbaikinya. Jika itu terjadi lagi, saya akan mengikuti saran @marns93 .

Kami telah menemukan masalah ini dan --exact-timestamps menyelesaikan masalah kami. Saya tidak yakin apakah masalahnya sama persis.

Saya melihat masalah ini, dan itu sangat jelas karena setiap panggilan hanya perlu menyalin beberapa (di bawah selusin) file.

Situasi yang terjadi seperti yang dilaporkan di atas: jika folder yang sync ed ke dalamnya berisi file dengan konten file yang berbeda tetapi ukuran file yang sama, sync akan melewatkan penyalinan file baru yang diperbarui dari S3.

Kami akhirnya mengubah skrip menjadi aws s3 cp --recursive untuk memperbaikinya, tetapi ini adalah bug yang buruk -- untuk waktu yang lama kami pikir kami memiliki semacam kondisi balapan di aplikasi kami sendiri, tidak menyadari bahwa aws-cli hanyalah memilih untuk tidak menyalin file yang diperbarui.

Saya melihat ini juga dengan file html

aws-cli/1.16.168 Python/3.6.0 Windows/2012ServerR2 botocore/1.12.158

Saya menyalin dan menempelkan perintah s3 sync dari GitHub Gist dan memiliki --size-only disetel. Menghapus itu memperbaiki masalah!

Baru saja mengalami masalah ini dengan artefak build yang diunggah ke bucket. HTML kami cenderung hanya mengubah kode hash untuk tautan aset sehingga ukurannya selalu sama. Sinkronisasi S3 melewatkan ini jika build terlalu cepat setelah build sebelumnya. Contoh:

10:01 - Build 1 run
10:05 - Build 2 run
10:06 - Build 1 diupload ke s3
10:10 - Build 2 diupload ke s3

Build 2 memiliki file HTML dengan stempel waktu 10:05, namun file HTML yang diunggah ke s3 oleh build 1 memiliki stempel waktu 10:06 karena saat itulah objek dibuat. Ini menyebabkan mereka diabaikan oleh sinkronisasi s3 karena file jarak jauh "lebih baru" daripada file lokal.

Saya sekarang menggunakan s3 cp --recursive diikuti oleh s3 sync --delete seperti yang disarankan sebelumnya.

Semoga ini bisa membantu seseorang.

Saya memiliki masalah yang sama awal minggu ini; Saya tidak menggunakan --size-only . index.html kami berbeda dengan satu karakter ( . menjadi # ), jadi ukurannya sama, tetapi stempel waktu pada s3 40 menit lebih awal dari stempel waktu indeks baru .html. Saya menghapus index.html sebagai solusi sementara, tetapi tidak mungkin untuk memeriksa ulang setiap penerapan.

Sama di sini, file dengan nama yang sama tetapi dengan cap waktu dan konten yang berbeda tidak disinkronkan dari S3 ke lokal dan --delete tidak membantu

Kami mengalami masalah yang sama. Index.html dengan ukuran yang sama tetapi stempel waktu yang lebih baru tidak disalin.

Masalah ini dilaporkan lebih dari setahun yang lalu. Mengapa tidak diperbaiki?

Sebenarnya itu membuat perintah snyc tidak berguna.

Waktu tepatnya

--exact-timestamps memperbaiki masalah

Saya juga terpengaruh oleh masalah ini. Saya menambahkan --exact-timestamps dan masalahnya sepertinya memperbaiki file yang saya lihat. saya belum melakukan pencarian yang lengkap. Saya memiliki urutan 100k file dan 20gb, jauh lebih sedikit daripada yang lain di sini.

Saya telah menghadapi masalah yang sama, aws s3 sync melewatkan beberapa file, bahkan dengan konten yang berbeda dan tanggal yang berbeda. Log menunjukkan bahwa file yang dilewati itu disinkronkan tetapi sebenarnya tidak.
Tetapi ketika saya menjalankan aws s3 sync lagi, file-file itu disinkronkan. Aneh sekali!

Saya mengalami masalah ini ketika membangun situs dengan Hugo dan akhirnya saya menemukan jawabannya. Saya menggunakan submodul untuk tema Hugo saya dan tidak menariknya ke CI. Ini menyebabkan peringatan di Hugo tetapi bukan kegagalan.

# On local
                   | EN
-------------------+-----
  Pages            | 16
  Paginator pages  |  0
  Non-page files   |  0
  Static files     |  7
  Processed images |  0
  Aliases          |  7
  Sitemaps         |  1
  Cleaned          |  0

# On CI
                   | EN  
-------------------+-----
  Pages            |  7  
  Paginator pages  |  0  
  Non-page files   |  0  
  Static files     |  2  
  Processed images |  0  
  Aliases          |  0  
  Sitemaps         |  1  
  Cleaned          |  0  

Setelah saya memperbarui submodul, semuanya berfungsi seperti yang diharapkan.

Kami juga telah terpengaruh oleh masalah ini, sedemikian rupa sehingga platform mati selama ~18 jam setelah file vendor/autoload.php baru tidak disinkronkan, dan vendor/composer/autoload_real.php kedaluwarsa seluruh aplikasi tidak dapat dimuat.

Ini adalah masalah _sangat_ aneh, dan saya tidak percaya masalah ini terbuka selama ini.

Mengapa sinkronisasi tidak menggunakan hash alih-alih diubah terakhir? Masuk akal.

Untuk Googler masa depan, saya mendapatkan kesalahan yang telah diedit:

PHP message: PHP Fatal error:  Uncaught Error: Class 'ComposerAutoloaderInitXXXXXXXXXXXXX' not found in /xxx/xxx/vendor/autoload.php:7
Stack trace:
#0 /xxx/xxx/bootstrap/app.php(3): require_once()
#1 /xxx/xxx/public/index.php(14): require('/xxx/xxx...')
#2 {main}
  thrown in /xxx/xxx/vendor/autoload.php on line 7" while reading response header from upstream: ...
---

Masalah yang sama, tidak semua file disinkronkan, --exact-timestamps tidak membantu.

aws --version
aws-cli/1.18.22 Python/2.7.13 Linux/4.14.152-127.182.amzn2.x86_64 botocore/1.15.22

Saya tidak percaya tiket ini dibuka begitu lama ... masalah yang sama di sini, di mana obsesi pelanggan Amazon?

Saya tidak percaya tiket ini tidak ditutup beberapa waktu lalu. Sejauh yang saya tahu, ini berfungsi seperti yang dirancang, tetapi pengguna (termasuk saya) membuat asumsi tentang cara kerjanya dan kemudian terkejut ketika itu tidak berperilaku seperti yang mereka harapkan.

• Saat file disinkronkan atau disalin _to_ s3, stempel waktu yang diterimanya di bucket adalah tanggal file disalin, yang _always_ lebih baru dari tanggal file sumber. Ini adalah bagaimana s3 bekerja.
• File hanya disinkronkan jika ukurannya berubah, atau stempel waktu pada target _lebih tua_ dari sumbernya.
• Ini berarti bahwa jika file sumber diperbarui tetapi ukuran file tetap tidak berubah dan tanggal pada file yang diubah tersebut lebih awal dari saat terakhir disalin, sinkronisasi s3 tidak akan menyinkronkannya lagi.
• Menggunakan --exact-timestamps _only_ berfungsi saat menyalin dari s3 ke lokal. Ini sengaja tidak diaktifkan untuk lokal ke s3 karena stempel waktu _tidak pernah_ sama. Jadi mengaturnya saat menyinkronkan dari lokal ke s3 tidak berpengaruh.
• Saya tidak berpikir s3 menghitung hash untuk file yang diunggah, jadi tidak ada cara untuk menghindari ukuran file dan tanggal unggahan terakhir sebagai pemeriksaan.

Intinya adalah ini berfungsi sebagaimana dimaksud, tetapi ada berbagai kasus penggunaan di mana ini tidak diinginkan. Seperti disebutkan di atas, saya telah mengatasinya menggunakan s3 cp --recursive

@jam13 terima kasih atas penjelasannya, sekarang semuanya masuk akal!

Namun demikian, saya berpendapat bahwa saat ini didokumentasikan dengan buruk (saya akan mengharapkan peringatan merah gemuk dalam dokumentasi yang menyatakan bahwa --exact-timestamps hanya berfungsi _dari s3 ke local_ dan juga untuk s3 cli hanya menyelamatkan alih-alih diam-diam mengabaikan parameter) dan mode perbandingan berbasis hash opsional diperlukan untuk menerapkan mode sinkronisasi yang bekerja dengan andal.

Ya, dokumentasinya tidak bagus, dan mengabaikan opsi secara diam-diam sangat tidak membantu. Tidak adanya manajemen atau bahkan komentar resmi tentang tiket ini dari AWS selama 2 tahun terakhir juga berbicara banyak.

@ jam13 Saya menggali beberapa dokumentasi, dan mengetahui bahwa saya perlu --exact-timestamps untuk menghindari beberapa masalah dari s3 ke lokal. Terima kasih!

@kyleknap @KaibaLopez @stealthycoin ada pembaruan untuk yang satu ini?

Saya tidak percaya tiket ini tidak ditutup beberapa waktu lalu. Sejauh yang saya tahu, ini berfungsi seperti yang dirancang, tetapi pengguna (termasuk saya) membuat asumsi tentang cara kerjanya dan kemudian terkejut ketika itu tidak berperilaku seperti yang mereka harapkan.

* When a file is synced or copied _to_ s3, the timestamp it receives on the bucket is the date it was copied, which is _always_ newer than the date of the source file. This is just how s3 works.

* Files are only synced if the size changes, or the timestamp on the target is _older_ than the source.

* This means that if source files are updated but the size of the files remains unchanged and the dates on those changed files pre-date when they were last copied, s3 sync will not sync them again.

* Using `--exact-timestamps` _only_ works when copying from s3 to local. It is deliberately not enabled for local to s3 because the timestamps are _never_ equal. So setting it when syncing from local to s3 has no effect.

* I don't think s3 calculates hashes for uploaded files, so there's no way of avoiding file size and last uploaded date as checks.

Intinya adalah ini berfungsi sebagaimana dimaksud, tetapi ada berbagai kasus penggunaan di mana ini tidak diinginkan. Seperti disebutkan di atas, saya telah mengatasinya menggunakan s3 cp --recursive

s3 melakukan hash pada objek, tetapi tidak dengan cara yang sepenuhnya dapat diketahui jika Anda bukan pengunggah , dan menyimpannya sebagai ETag yang sudah dikenal. Masalahnya adalah ETag tergantung pada jumlah potongan dan ukuran potongan yang digunakan saat file diunggah. Jika Anda bukan pengunggah, Anda mungkin tidak mengetahui ukuran potongan (tetapi bisa mendapatkan jumlah potongan dari ETag). Saya tidak tahu mengapa hal itu dilakukan dengan cara ini.

Ini mungkin berfungsi sebagaimana dimaksud, tetapi tidak berfungsi sebagaimana mestinya. Seharusnya sepele untuk memeriksa apakah file telah berubah

Ini hanya masalah besar bagi orang-orang yang secara tak terduga mengalami ketidaksinkronan
data. Ada 100 solusi berbeda yang dapat menyelamatkan semua orang di sini
waktu membaca tiket ini, bersama dengan waktu yang dihabiskan untuk menemukan ini
adalah masalah dalam kode sumber mereka. Mengapa mereka tidak bisa melakukan salah satunya?

Pada Selasa, 14 April 2020 pukul 13:57 Keith Kelly [email protected]
menulis:

Saya tidak percaya tiket ini tidak ditutup beberapa waktu lalu. Sejauh yang saya bisa
katakan, ini berfungsi seperti yang dirancang, tetapi pengguna (termasuk saya) membuat asumsi tentang
bagaimana seharusnya bekerja dan kemudian terkejut ketika tidak berperilaku bagaimana mereka
mengharapkan.

• Saat file disinkronkan atau disalin _to_ s3, stempel waktu yang diterimanya di bucket adalah tanggal file disalin, yang _always_ lebih baru dari tanggal file sumber. Ini adalah bagaimana s3 bekerja.

• File hanya disinkronkan jika ukurannya berubah, atau stempel waktu pada target _lebih tua_ dari sumbernya.

• Ini berarti bahwa jika file sumber diperbarui tetapi ukuran file tetap tidak berubah dan tanggal pada file yang diubah tersebut lebih awal dari saat terakhir disalin, sinkronisasi s3 tidak akan menyinkronkannya lagi.

• Menggunakan --exact-timestamps _only_ berfungsi saat menyalin dari s3 ke lokal. Ini sengaja tidak diaktifkan untuk lokal ke s3 karena stempel waktu _tidak pernah_ sama. Jadi mengaturnya saat menyinkronkan dari lokal ke s3 tidak berpengaruh.

• Saya tidak berpikir s3 menghitung hash untuk file yang diunggah, jadi tidak ada cara untuk menghindari ukuran file dan tanggal unggahan terakhir sebagai pemeriksaan.

Intinya adalah itu berfungsi sebagaimana dimaksud, tetapi ada berbagai kasus penggunaan
dimana hal ini tidak diinginkan. Seperti yang disebutkan di atas
<#m_8540343689970969812_issuecomment-534061850> Saya telah mengatasinya
menggunakan s3 cp --recursive

s3 melakukan hash pada objek, tetapi tidak dengan cara yang sepenuhnya dapat diketahui
https://teppen.io/2018/10/23/aws_s3_verify_etags/ , dan simpan ini sebagai
ETag yang sudah dikenal https://en.wikipedia.org/wiki/HTTP_ETag . Masalah
adalah bahwa ETag tergantung pada jumlah potongan dan ukuran potongan itu
file diunggah. Jika Anda bukan pengunggah, Anda mungkin tidak melakukannya
tahu ukuran potongan (tetapi bisa mendapatkan jumlah potongan dari ETag). Saya
tidak tahu mengapa hal itu dilakukan dengan cara ini.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/aws/aws-cli/issues/3273#issuecomment-613677369 , atau
berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ADUA4NKJMCUSGTNAAITGPXTRMTE2NANCNFSM4E3JNHPQ
.

>

... tom

Punya masalah yang sama. Selesaikan dengan mengubah kebijakan ember sumber menjadi:

 "Action": [
                "s3:*"
            ],

Saya punya masalah dengan cp --recursive dan sync .
Ini menyelesaikan semuanya. Saya memiliki dua tindakan yang seharusnya berfungsi dengan baik, tetapi tidak. Cobalah dan beri tahu saya jika itu menyelesaikan masalah Anda.

Berdebat di sini untuk mengatakan bahwa saya juga mengalami masalah dengan sync . Satu-satunya alasan yang saya perhatikan adalah karena saya menyegel dan memverifikasi MHL di kedua ujungnya. sync tidak akan berfungsi, dan saya kehilangan sekitar 60 GB dari 890 GB, mencoba menelusuri, folder demi folder. Kemudian saya menemukan utas ini dan mencoba cp --recursive dan data mulai mengalir lagi. Akan memverifikasi MHL untuk terakhir kalinya setelah saya mendapatkan sisa data ini.

Saya menulis skrip untuk mereproduksi masalah, saya menggunakan:
aws-cli/1.18.34 Python/2.7.17 Darwin/19.4.0 botocore/1.13.50

Jika Anda menjalankan skrip, Anda akan melihat bahwa setelah mengunggah perubahan, perubahan yang sama tidak diunduh lagi. Ini skripnya:

#!/bin/bash
PROFILE=foobar #PUT YOUR PROFILE HERE
BUCKET=baz123  #PUT YOUR BUCKET HERE

mkdir -p test/local
mkdir -p test/s3

cat >test/s3/test.json <<EOF
{
  "__comment_logging": "set cookie expiration time of aws split, examples '+1 hour', '+5 days', '+100 days'",
  "splitCookieExpiration": "+3 hours"
}
EOF

#UPLOAD
aws --profile=$PROFILE s3 sync --delete test/s3 s3://$BUCKET/ 
#DOWNLOAD
aws --profile=$PROFILE s3 sync --delete s3://$BUCKET/ test/local


#CHANGE 
cat >test/s3/test.json <<EOF
{
  "__comment_logging": "set cookie expiration time of aws split, examples '+1 hour', '+5 days', '+100 days'",
  "splitCookieExpiration": "+2 hours"
}
EOF


#UPLOAD
aws --profile=$PROFILE s3 sync --delete test/s3 s3://$BUCKET/ 
#DOWNLOAD
aws --profile=$PROFILE s3 sync --delete s3://$BUCKET/ test/local

@htrappmann Silakan baca @jam13 answer https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439 sebelumnya — ini bukan bug, ini fitur!

Terima kasih atas petunjuknya @applerom , tapi saya benar-benar tidak mengerti bagaimana @jam13 mendeklarasikannya sebagai "berfungsi seperti yang dirancang". Alat sinkronisasi harus dirancang untuk menjaga sumber dan tujuan tetap sama, dan ini tidak diberikan dengan sinkronisasi ini. Yang menjadikannya tidak berguna untuk banyak aplikasi.

Juga jika ukuran file tidak berubah tetapi cap waktu sumber lebih baru juga tidak ada sinkronisasi yang terjadi, seperti pada contoh skrip saya.

Terima kasih atas petunjuknya @applerom , tapi saya benar-benar tidak mengerti bagaimana @jam13 mendeklarasikannya sebagai "berfungsi seperti yang dirancang". Alat sinkronisasi harus dirancang untuk menjaga sumber dan tujuan tetap sama, dan ini tidak diberikan dengan sinkronisasi ini. Yang menjadikannya tidak berguna untuk banyak aplikasi.

Juga jika ukuran file tidak berubah tetapi cap waktu sumber lebih baru juga tidak ada sinkronisasi yang terjadi, seperti pada contoh skrip saya.

Itu memang terlihat seperti melakukan hal yang salah bukan.

Saya menjalankan beberapa tes lain untuk melihat apa yang sebenarnya perlu saya lakukan agar unduhan terjadi:

ls -l test/local/test.json
aws s3 sync --delete s3://$BUCKET/ test/local
touch -m -t 201901010000 test/local/test.json
ls -l test/local/test.json
aws s3 sync --delete s3://$BUCKET/ test/local
touch test/local/test.json
ls -l test/local/test.json
aws s3 sync --delete s3://$BUCKET/ test/local

Saat mengubah waktu modifikasi file ke tahun lalu, sinkronisasi s3 masih tidak mengunduh file, jadi ini bukan hanya masalah zona waktu.

Saat mengubah waktu modifikasi menjadi sekarang (jadi file lokal lebih baru daripada remote), s3 sync _melakukan_ unduh file!

Saya tidak dapat memahaminya, jadi saya memeriksa dokumen, yang menyatakan (ketika menjelaskan opsi --exact-timestamps ):

Perilaku default adalah mengabaikan item berukuran sama kecuali versi lokal lebih baru dari versi S3.

Menggunakan --exact-timestamps untuk mengunduh berfungsi seperti yang diharapkan (setiap perbedaan dalam stempel waktu menghasilkan salinan), tetapi default ini tampaknya mundur bagi saya.

Mungkin alih-alih mengatakan "berfungsi seperti yang dirancang", saya seharusnya mengatakan "berfungsi seperti yang didokumentasikan".

@jam13 Wow itu sangat aneh, dan saya pikir ini adalah kebingungan dalam dokumentasi!
Tetapi jika ini adalah cara baru untuk memperbaiki bug, dengan hanya secara eksplisit memasukkannya ke dalam dokumentasi ...

@jam13

Saya tidak yakin apakah kami dapat mengesampingkan masalah zona waktu.
Setiap hari, ketika saya membuat perubahan pertama di konsol s3, dan menyinkronkan aws s3 sync s3://$BUCKET . , itu disinkronkan. Jika saya membuat perubahan lain pada file, dan kemudian menyinkronkan, itu tidak disinkronkan.
Tapi itu bekerja pada hari berikutnya.

Ini membuat saya berpikir ulang jika bisa karena zona waktu.

Jadi periksa sedikit lebih banyak tentang perintah touch -m yang telah Anda sebutkan di atas.

touch -m -t 201901010000 test/local/test.json
Saat mengubah waktu modifikasi file ke tahun lalu, sinkronisasi s3 masih tidak mengunduh file, jadi ini bukan hanya masalah zona waktu.

Perintah sentuh di atas hanya memundurkan waktu mtime. Itu tidak (dan tidak bisa) memundurkan waktu ctime.
Apakah cli S3 mungkin menggunakan ctime?

$ touch file
$ stat -x file
  File: "file"
  Size: 0            FileType: Regular File
  ...
  ...
Access: Mon Jul 20 21:59:11 2020
Modify: Mon Jul 20 21:59:11 2020
Change: Mon Jul 20 21:59:11 2020

$ touch -m -t 201901010000 file
$ stat -x file
  File: "file"
  Size: 0            FileType: Regular File
  ...
  ...
Access: Mon Jul 20 21:59:11 2020
Modify: Tue Jan  1 00:00:00 2019
Change: Mon Jul 20 22:01:48 2020

Saya pikir sinkronisasi file harus menjamin file secara lokal, dan dari jarak jauh sama. Saya tidak berpikir saya tidak adil mengatakan itu. Saya pikir aws s3 sync lebih merupakan update , daripada sinkronisasi. Saya sekarang akan mengubah setiap implementasi aws s3 sync menjadi aws s3 cp --recursive .

Terima kasih @jam13 atas penjelasannya di https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439