Aws-cli: لا تقوم مزامنة AWS S3 بمزامنة جميع الملفات

يمكنك استخدام --exact-timestamps للتغلب على هذا ، على الرغم من أن ذلك قد يؤدي إلى تحميلات زائدة إذا كنت تقوم بالتحميل.

للمساعدة في إعادة الإنتاج ، هل يمكنك الحصول على بعض المعلومات حول أحد الملفات التي لا تتم مزامنتها؟

• ما هو حجم الملف الدقيق محليًا؟
• ما هو حجم الملف الدقيق في S3؟
• ما هو وقت آخر تعديل محليًا؟
• ما هو وقت آخر تعديل في S3؟
• هل الملف المحلي عبارة عن ارتباط رمزي / خلف ارتباط رمزي؟

مثال على تشغيل الأمر
aws s3 sync s3: // bucket / / var / www / folder / --delete

عدة ملفات مفقودة
الحجم المحلي الدقيق: 2625
المطابقة s3: 2625
الطابع الزمني الدقيق المحلي: 06-يناير -2017 9:32:31
الطابع الزمني الدقيق s3: 20-Jun-2017 10:14:57
ملف عادي في S3 والمحلية

هناك عدة حالات من هذا القبيل في قائمة تضم حوالي 50000 ملف. ومع ذلك ، فإن جميع عمليات المزامنة المفقودة تكون في أوقات مختلفة في 20 يونيو 2017.

يُظهر استخدام --exact-timestamps المزيد من الملفات للتنزيل على الرغم من أنها نفس المحتويات تمامًا. ومع ذلك ، ما زالوا يفتقدون إلى تلك الموجودة في المثال أعلاه.

نفس المشكلة هنا.
لم يقم aws s3 sync dist/ s3://bucket --delete بتحميل s3: //bucket/index.html مع dist / index.html

dist / index.html و s3: //bucket/index.html لهما نفس حجم الملف ، لكن وقت تعديلهما مختلف.

في الواقع ، في بعض الأحيان قام awscli بتحميل الملف ، لكن في بعض الأحيان لم يفعل ذلك

كذلك هنا ، --exact-timestamps لا يساعد - index.html لا يتم الكتابة فوقه.

لقد عانينا من هذه المشكلة بشكل جيد اليوم / الأسبوع الماضي. مرة أخرى ، يكون index.html هو نفس حجم الملف ، لكن المحتويات والأوقات المعدلة مختلفة.

هل يعلم أي شخص حل بديل لهذا؟

أنا فقط جريت في هذا. نفس المشكلة التي أبلغ عنها icymind و samdammers : لقد index.html ، لكن حجم ملفه كان هو نفسه النسخة السابقة في S3. لم يقم الأمر {{aws s3 sync}} بتحميله. كان "الحل البديل" الخاص بي هو حذف index.html من S3 ، ثم تشغيل المزامنة مرة أخرى (والتي بعد ذلك تم تحميلها كما لو كانت ملفًا جديدًا ، على ما أعتقد).

الخادم: EC2 linux
الإصدار: aws-cli/1.16.108 Python/2.7.15 Linux/4.9.62-21.56.amzn1.x86_64 botocore/1.12.98

بعد تشغيل aws s3 sync يزيد عن 270 تيرابايت من البيانات ، فقدت بضعة غيغابايت من الملفات. لم تقم المزامنة بنسخ الملفات ذات الأحرف الخاصة على الإطلاق.

مثال على الملف /data/company/storage/projects/1013815/3.Company Estimates/B. Estimates

اضطررت إلى استخدام cp -R -n

نفس المشكلة هنا ملف xml بالحجم نفسه ولكن الطابع الزمني المختلف لم تتم مزامنته بشكل صحيح

لقد تمكنت من إعادة إنتاج هذه المشكلة

bug.tar.gz
قم بتنزيل ملف tar المرفق ثم

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

ستلاحظ أنه على الرغم من أن ملف repomd.xml في الدللين أ و ب يختلفان في المحتويات والطوابع الزمنية
محاولة مزامنة ب لا تفعل أي شيء

اختبارها على
aws-cli / 1.16.88 Python / 2.7.15 داروين / 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

أنا أرى نفس المشكلة. محاولة مزامنة دليل من الملفات من s3 حيث تم تحديث ملف واحد إلى دليل محلي. لا يتم تحديث هذا الملف في الدليل المحلي

أنا أرى هذا أيضًا. في حالتي ، إنه تطبيق تفاعلي مع index.html يشير إلى ملفات .js التي تم إنشاؤها. أنا أقوم بمزامنتها مع خيار --delete لحذف الملفات القديمة التي لم يعد يشار إليها. في بعض الأحيان لا يتم تحميل index.html ، مما ينتج عنه ملف index.html قديم يشير إلى ملفات .js التي لم تعد موجودة.

ومن ثم توقف موقع الويب الخاص بي عن العمل !!!

أنا جاهل حاليًا عن سبب حدوث ذلك.

هل لدى أي شخص أي أفكار أو حلول؟

لدينا نفس المشكلة ، لكننا توصلنا للتو إلى حل بديل. أعلم أنها ليست أفضل طريقة لكنها تعمل:

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

يبدو لنا أن النسخة تعمل بشكل جيد ، لذلك نقوم أولاً بالنسخ بعد ذلك نستخدم أمر المزامنة لحذف الملفات التي لم تعد موجودة.
آمل أن يتم إصلاح المشكلة في أسرع وقت ممكن.

أضفت --exact-timestamps إلى خط الأنابيب الخاص بي ولم تتكرر المشكلة. لكنها كانت متقطعة في المقام الأول لذا لا يمكنني التأكد من إصلاحها. إذا حدث ذلك مرة أخرى ، فسأختار اقتراح

لقد واجهنا هذه المشكلة و --exact-timestamps حل مشكلتنا. لست متأكدًا مما إذا كانت نفس المشكلة بالضبط.

أرى هذه المشكلة ، وهي واضحة جدًا لأن كل مكالمة يجب أن تنسخ فقط عددًا قليلاً (أقل من عشرة ملفات).

الموقف الذي يحدث فيه هو تمامًا كما ورد أعلاه: إذا كان المجلد sync ed فيه يحتوي على ملف بمحتويات ملف مختلفة ولكن بنفس حجم الملف ، فإن sync سيتخطى نسخ الملف المحدث الجديد من S3.

لقد انتهينا من تغيير البرامج النصية إلى aws s3 cp --recursive لإصلاحها ، لكن هذا خطأ سيئ - لأطول فترة اعتقدنا أن لدينا نوعًا من حالة السباق في تطبيقنا ، ولم ندرك أن aws-cli كان ببساطة اختيار عدم نسخ الملف (الملفات) المحدثة.

رأيت هذا أيضًا مع ملف html

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

لقد قمت بنسخ الأمر s3 sync من جوهر GitHub وكان عليه --size-only تعيينه عليه. إزالة هذا حل المشكلة!

واجهت للتو هذه المشكلة مع تحميل عناصر البناء إلى حاوية. تميل HTML الخاص بنا إلى تغيير رموز التجزئة فقط لروابط الأصول ولذا كان الحجم دائمًا هو نفسه. كانت مزامنة S3 تتخطى هذه إذا كان الإصدار بعد وقت قصير جدًا من الإصدار السابق. مثال:

10:01 - بناء 1 أشواط
10:05 - بناء 2 أشواط
10:06 - تم تحميل النسخة 1 إلى s3
10:10 - تم تحميل النسخة 2 إلى s3

يحتوي الإصدار 2 على ملفات HTML بطابع زمني 10:05 ، ومع ذلك ، فإن ملفات HTML التي تم تحميلها إلى s3 من خلال الإصدار 1 لها طابع زمني يبلغ 10:06 عندما تم إنشاء الكائنات. ينتج عن هذا تجاهلها بواسطة مزامنة s3 لأن الملفات البعيدة "أحدث" من الملفات المحلية.

أنا الآن أستخدم s3 cp --recursive follow by s3 sync --delete كما اقترح سابقًا.

أتمنى أن يكون هذا مفيدًا لشخص ما.

واجهت نفس المشكلة في وقت سابق من هذا الأسبوع ؛ لم أكن أستخدم --size-only . كان index.html مختلفًا عن طريق حرف واحد ( . ذهب إلى # ) ، لذا كان الحجم هو نفسه ، لكن الطابع الزمني في s3 كان قبل 40 دقيقة من الطابع الزمني للفهرس الجديد .لغة البرمجة. لقد حذفت ملف index.html كحل مؤقت ، ولكن من غير المجدي التحقق مرة أخرى من كل عملية نشر.

الشيء نفسه هنا ، لا تتم مزامنة الملفات التي تحمل نفس الاسم ولكن ذات طابع زمني ومحتوى مختلفين من S3 إلى محلي و - الحذف لا يساعد

نحن نواجه نفس المشكلة. لا يتم نسخ ملف index.html بالحجم نفسه ولكن طابع زمني أحدث.

تم الإبلاغ عن هذه المشكلة منذ أكثر من عام. لماذا لم يتم إصلاحه؟

في الواقع يجعل الأمر snyc عديم الفائدة.

الوقت بالضبط

- الطوابع الزمنية الدقيقة أصلحت المشكلة

أنا أيضا متأثر بهذه القضية. أضفت - الطوابع الزمنية الدقيقة ويبدو أن المشكلة تعمل على إصلاح الملفات التي كنت أبحث عنها. لم أقم ببحث شامل. لدي ملفات بترتيب 100 ألف و 20 غيغابايت ، أقل بكثير من الملفات الأخرى هنا.

لقد واجهت نفس المشكلة ، aws s3 sync تخطي بعض الملفات ، حتى مع اختلاف المحتويات والتواريخ. يُظهر السجل أن هذه الملفات التي تم تخطيها تتم مزامنتها ولكنها في الواقع لا تتم مزامنتها.
ولكن عندما أقوم بتشغيل aws s3 sync مرة أخرى ، تمت مزامنة هذه الملفات. غريب جدا!

واجهت هذه المشكلة عند إنشاء موقع باستخدام Hugo ، وقد اكتشفته أخيرًا. أستخدم وحدات فرعية لموضوع Hugo الخاص بي ولم أقم بإزالتها على CI. كان هذا يسبب تحذيرات في Hugo ولكن ليس الفشل.

# 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  

بمجرد أن قمت بتحديث الوحدات الفرعية ، كل شيء يعمل كما هو متوقع.

لقد تأثرنا أيضًا بهذه المشكلة ، لدرجة أن النظام الأساسي توقف لمدة 18 ساعة تقريبًا بعد عدم مزامنة ملف vendor/autoload.php ، وكان قديمًا مع vendor/composer/autoload_real.php لذا لا يمكن تحميل التطبيق بالكامل.

هذه مشكلة غريبة جدًا ، ولا أصدق أن المشكلة ظلت مفتوحة لفترة طويلة.

لماذا لا تستخدم المزامنة علامات التجزئة بدلاً من آخر تعديل؟ يجعل 0 معنى.

لموظفي Google المستقبليين ، كنت أتلقى خطأ منقحًا:

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: ...
---

نفس المشكلة ، لم تتم مزامنة جميع الملفات ، --exact-timestamps لم يساعد.

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

لا أستطيع أن أصدق أن هذه التذكرة مفتوحة لفترة طويلة ... نفس المشكلة هنا ، أين هوس عملاء أمازون؟

لا أصدق أن هذه التذكرة لم تغلق منذ بعض الوقت. بقدر ما أستطيع أن أقول ، إنه يعمل كما هو مصمم ، لكن المستخدمين (بمن فيهم أنا) يضعون افتراضات حول كيفية عمله ثم يفاجأون عندما لا يتصرفون بالطريقة التي توقعوها.

• عند مزامنة ملف أو نسخه _to_ s3 ، فإن الطابع الزمني الذي يتلقاه في الحاوية هو تاريخ نسخه ، وهو _ دائمًا _ أحدث من تاريخ الملف المصدر. هذه هي الطريقة التي يعمل بها s3.
• تتم مزامنة الملفات فقط إذا تغير الحجم ، أو إذا كان الطابع الزمني على الهدف هو _older_ من المصدر.
• هذا يعني أنه إذا تم تحديث ملفات المصدر ولكن ظل حجم الملفات دون تغيير وأن التواريخ الموجودة على تلك الملفات التي تم تغييرها تسبق تاريخ نسخها آخر مرة ، فلن تقوم مزامنة s3 بمزامنتها مرة أخرى.
• يعمل استخدام --exact-timestamps _only_ عند النسخ من s3 إلى محلي. لم يتم تمكينه عمدًا للمحلي حتى s3 لأن الطوابع الزمنية ليست متساوية أبدًا. لذا فإن تعيينه عند المزامنة من المحلي إلى s3 ليس له أي تأثير.
• لا أعتقد أن s3 يحسب التجزئات للملفات التي تم تحميلها ، لذلك لا توجد طريقة لتجنب حجم الملف وآخر تاريخ تم تحميله كشيكات.

خلاصة القول هي أنه يعمل على النحو المنشود ، ولكن هناك حالات استخدام مختلفة حيث يكون هذا غير مرغوب فيه. كما هو مذكور أعلاه ، فقد عملت حوله باستخدام s3 cp --recursive

@ jam13 شكرًا على التفسير ، والآن أصبح كل شيء منطقيًا بعد فوات الأوان!

ومع ذلك ، أود أن أزعم أنه موثق حاليًا بشكل سيئ (كنت أتوقع تحذيرًا أحمر باهتًا في الوثائق ينص على أن --exact-timestamps يعمل فقط _ من s3 إلى local_ وأيضًا لـ s3 cli لإنقاذ بدلاً من الصمت تجاهل المعلمة) ووضع مقارنة اختياري قائم على التجزئة ضروري لتنفيذ وضع مزامنة يعمل بشكل موثوق.

نعم ، التوثيق ليس رائعًا ، وتجاهل الخيارات بصمت غير مفيد للغاية. إن عدم وجود أي إدارة أو حتى تعليقات رسمية على هذه التذكرة من AWS على مدار العامين الماضيين يتحدث أيضًا عن الكثير.

@ jam13 لقد

kyleknapKaibaLopezstealthycoin أي تحديث على هذا واحد؟

لا أصدق أن هذه التذكرة لم تغلق منذ بعض الوقت. بقدر ما أستطيع أن أقول ، إنه يعمل كما هو مصمم ، لكن المستخدمين (بمن فيهم أنا) يضعون افتراضات حول كيفية عمله ثم يفاجأون عندما لا يتصرفون بالطريقة التي توقعوها.

* 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.

خلاصة القول هي أنه يعمل على النحو المنشود ، ولكن هناك حالات استخدام مختلفة حيث يكون هذا غير مرغوب فيه. كما هو مذكور أعلاه ، فقد عملت حوله باستخدام s3 cp --recursive

يقوم s3 بتجزئة العناصر ، ولكن ليس بطريقة معروفة تمامًا إذا لم تكن القائم بالتحميل ، ويقوم بتخزينها على أنها ETag المألوف. تكمن المشكلة في أن ETag يعتمد على عدد الأجزاء وحجم المقطع المستخدم عند تحميل الملف. إذا لم تكن القائم بالتحميل ، فمن المحتمل أنك لا تعرف حجم القطعة (ولكن يمكنك الحصول على عدد القطع من ETag). لا أعرف لماذا يتم ذلك بهذه الطريقة.

ربما يعمل هذا على النحو المنشود ، لكنه لا يعمل كما ينبغي. يجب أن يكون التحقق مما إذا كان الملف قد تغير أم لا

إنها مجرد مسكتك كبير للأشخاص لتجربة بشكل غير متوقع خارج المزامنة
البيانات. هناك 100 حل مختلف يمكن أن ينقذ الجميع هنا
وقت قراءة هذه التذكرة ، بالإضافة إلى الوقت المستغرق في اكتشاف ذلك
كانت مشكلة في التعليمات البرمجية المصدر الخاصة بهم. لماذا لا يستطيعون فعل واحد من هؤلاء؟

يوم الثلاثاء 14 أبريل 2020 الساعة 1:57 مساءً Keith Kelly [email protected]
كتب:

لا أصدق أن هذه التذكرة لم تغلق منذ بعض الوقت. بقدر ما أستطيع
أقول ، إنه يعمل حسب التصميم ، لكن المستخدمين (بمن فيهم أنا) يضعون افتراضات حول
كيف يجب أن تعمل ثم تتفاجأ عندما لا تتصرف بالطريقة التي يتصرفون بها
متوقع.

• عند مزامنة ملف أو نسخه _to_ s3 ، فإن الطابع الزمني الذي يتلقاه في الحاوية هو تاريخ نسخه ، وهو _ دائمًا _ أحدث من تاريخ الملف المصدر. هذه هي الطريقة التي يعمل بها s3.

• تتم مزامنة الملفات فقط إذا تغير الحجم ، أو إذا كان الطابع الزمني على الهدف هو _older_ من المصدر.

• هذا يعني أنه إذا تم تحديث ملفات المصدر ولكن ظل حجم الملفات دون تغيير وأن التواريخ الموجودة على تلك الملفات التي تم تغييرها تسبق تاريخ نسخها آخر مرة ، فلن تقوم مزامنة s3 بمزامنتها مرة أخرى.

• يعمل استخدام --exact-timestamps _only_ عند النسخ من s3 إلى محلي. لم يتم تمكينه عمدًا للمحلي حتى s3 لأن الطوابع الزمنية ليست متساوية أبدًا. لذا فإن تعيينه عند المزامنة من المحلي إلى s3 ليس له أي تأثير.

• لا أعتقد أن s3 يحسب التجزئات للملفات التي تم تحميلها ، لذلك لا توجد طريقة لتجنب حجم الملف وآخر تاريخ تم تحميله كشيكات.

خلاصة القول هي أنه يعمل على النحو المنشود ، ولكن هناك حالات استخدام مختلفة
حيث هذا غير مرغوب فيه. كما ذكر أعلاه
<# m_8540343689970969812_issuecomment-534061850> لقد عملت حوله
باستخدام s3 cp - متسلسل

يقوم s3 بتجزئة العناصر ، ولكن ليس بطريقة معروفة تمامًا
https://teppen.io/2018/10/23/aws_s3_verify_etags/ ، ويخزن هذا كـ
ETag المألوف https://en.wikipedia.org/wiki/HTTP_ETag . المشكلة
هو أن ETag يعتمد على عدد القطع وحجم القطعة ذلك
تم تحميل الملف في. إذا لم تكن القائم بالتحميل ، فمن المحتمل أنك لا تفعل ذلك
تعرف على حجم القطعة (ولكن يمكنك الحصول على عدد القطع من ETag). أنا
لا أعرف لماذا يتم ذلك بهذه الطريقة.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/aws/aws-cli/issues/3273#issuecomment-613677369 ، أو
إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ADUA4NKJMCUSGTNAAITGPXTRMTE2NANCNFSM4E3JNHPQ
.

>

... توم

كان لديه نفس المشكلة. تم حلها بتغيير سياسة حاوية المصدر إلى:

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

واجهت مشكلة مع كل من cp --recursive و sync .
هذا حل كل شيء. كان لدي فعلان كان من المفترض أن يعملا على ما يرام ، لكن لم يحدث ذلك. جربها واسمحوا لي أن أعرف ما إذا كان قد أدى إلى حل مشكلتك.

تتناغم هنا لتقول إنني أيضًا أواجه مشكلة مع sync . السبب الوحيد الذي لاحظته هو أنني كنت أقوم بإغلاق MHLs والتحقق منها من كلا الطرفين. sync ، وكنت أفتقد حوالي 60 غيغابايت من أصل 890 غيغابايت ، وأنا أحاول المرور ، مجلدًا تلو الآخر. ثم وجدت هذا الموضوع وحاولت cp --recursive وبدأت البيانات تتدفق مرة أخرى. سيتم التحقق من MHL مرة أخيرة بمجرد حصولي على بقية هذه البيانات.

كتبت نصًا لإعادة إنتاج المشكلة ، أستخدم:
aws-cli / 1.18.34 Python / 2.7.17 داروين / 19.4.0 botocore / 1.13.50

إذا قمت بتنفيذ البرنامج النصي ، فسترى أنه بعد تحميل التغيير ، لن يتم تنزيل نفس التغيير بعد الآن. هذا هو النص:

#!/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 يرجى قراءة @ jam13 إجابة https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439 من قبل - إنها ليست خطأ ، إنها ميزة!

شكرًا على التلميح applerom ، لكنني حقًا لا أستطيع أن أفهم كيف يعلن @ jam13 أنه "يعمل حسب التصميم". يجب تصميم أداة المزامنة للحفاظ على تساوي المصدر والوجهة ، وهذا لا يتم توفيره مع هذه المزامنة. مما يجعلها غير مجدية للعديد من التطبيقات.

أيضًا إذا لم يتغير حجم الملف ولكن الطابع الزمني المصدر أحدث أيضًا ، فلن تحدث أي مزامنة ، كما هو الحال في المثال النصي الخاص بي.

شكرًا على التلميح applerom ، لكنني حقًا لا أستطيع أن أفهم كيف يعلن @ jam13 أنه "يعمل حسب التصميم". يجب تصميم أداة المزامنة للحفاظ على تساوي المصدر والوجهة ، وهذا لا يتم توفيره مع هذه المزامنة. مما يجعلها غير مجدية للعديد من التطبيقات.

أيضًا إذا لم يتغير حجم الملف ولكن الطابع الزمني المصدر أحدث أيضًا ، فلن تحدث أي مزامنة ، كما هو الحال في المثال النصي الخاص بي.

هذا يبدو وكأنه يفعل الشيء الخطأ ، أليس كذلك.

أجريت اختبارين آخرين لمعرفة ما أحتاجه فعلاً حتى يحدث التنزيل:

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

عند تغيير وقت تعديل الملف إلى العام الماضي ، لا تزال مزامنة s3 لا تقوم بتنزيل الملف ، لذا فهي ليست مجرد مشكلة منطقة زمنية.

عند تغيير وقت التعديل إلى الآن (بحيث يكون الملف المحلي أحدث من جهاز التحكم عن بُعد) ، يقوم s3 sync _does_ بتنزيل الملف!

لم أستطع فهم ذلك ، لذا راجعت المستندات ، أي حالة (عند وصف الخيار --exact-timestamps ):

السلوك الافتراضي هو تجاهل العناصر ذات الحجم نفسه ما لم يكن الإصدار المحلي أحدث من الإصدار S3.

يعمل استخدام --exact-timestamps للتنزيل كما هو متوقع (ينتج عن أي اختلاف في الطوابع الزمنية نسخة) ، ولكن هذا الإعداد الافتراضي يبدو عكسيًا بالنسبة لي.

ربما بدلاً من أن أقول "يعمل حسب التصميم" كان يجب أن أقول "يعمل كما هو موثق".

@ jam13 رائع ، هذا غريب جدًا ، واعتقدت أنه ارتباك في التوثيق!
ولكن إذا كانت هذه هي الطريقة الجديدة لإصلاح الأخطاء ، فما عليك سوى وضعها صراحةً في الوثائق ...

@ jam13

لست متأكدًا مما إذا كان بإمكاننا استبعاد مشكلة المنطقة الزمنية.
كل يوم ، عندما أقوم بإجراء التغيير الأول في وحدة التحكم s3 ، وأجري مزامنة aws s3 sync s3://$BUCKET . ، تتم المزامنة. إذا قمت بإجراء تغيير آخر على الملف ، ثم قمت بالمزامنة ، فلن تتم مزامنته.
لكنها تعمل في اليوم التالي.

هذا يجعلني أعيد التفكير فيما إذا كان ذلك بسبب المنطقة الزمنية.

لذلك تحقق قليلاً من الأمر touch -m الذي ذكرته أعلاه.

touch -m -t 201901010000 test/local/test.json
عند تغيير وقت تعديل الملف إلى العام الماضي ، لا تزال مزامنة s3 لا تقوم بتنزيل الملف ، لذا فهي ليست مجرد مشكلة منطقة زمنية.

أمر اللمس أعلاه يقوم فقط بتأريخ mtime. إنه لا (ولا يمكن) أن يقوم بتأريخ ctime.
هل S3 cli ربما تستخدم 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

أعتقد أن مزامنة الملفات يجب أن تضمن الملفات محليًا ، وهي نفسها عن بُعد. لا أعتقد أنني غير منصف في قول ذلك. أعتقد أن aws s3 sync هو أكثر من update من المزامنة. سأقوم الآن بتغيير كل تنفيذ من aws s3 sync إلى aws s3 cp --recursive .

شكرا @ jam13 على https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439