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

آه: https://forums.aws.amazon.com/thread.jspa؟messageID=203510&state=hashArgs٪23203510

لقد وجدته :-)

- سب

في 17 كانون الثاني (يناير) 2014 ، الساعة 16:26 ، كتب Jeff Waugh < [email protected] [email protected] >:

آه: https://forums.aws.amazon.com/thread.jspa؟messageID=203510&state=hashArgs٪23203510

-
يمكنك الرد على هذه الرسالة الإلكترونية مباشرةً أو عرضها على Gi tHubhttps: //github.com/aws/aws-cli/issues/599#issuecomment -32668382.

Amazon EU Societe a responsabilite limitee، 5 Rue Plaetis، L - 2338 Luxembourg، RCS Luxembourg n B 101818، capital social: EUR 37.500. Autorisation d establissement en qualite de commercante n 104408.

نعم ، لا يمكننا حساب ETag بشكل موثوق لعمليات التحميل متعددة الأجزاء ، وإلا فسيكون ذلك حلاً رائعًا.

هل يمكنك إضافة علم جديد (أو 2) لسلوك الوقت؟ ربما --check-timestamps للخيار 1 و --update-local-timestamps للخيار 2. بهذه الطريقة يمكن للمستخدم تحديد فحص أكثر قوة للتغييرات وقبول العواقب في نفس الوقت.

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

jamesls أنا أستخدم أمر المزامنة لنشر موقع ويب ثابت تم إنشاؤه.

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

من أجل أغراضي (وأتخيل عددًا صحيًا من الأشخاص الآخرين الذين يستخدمون هذه الأداة الرائعة لتحميل مواقعهم الثابتة) ، فإن المزامنة عبر ETag كما هو مقترح في # 575 ستكون أكثر روعة ، ولكن بالنظر إلى قراءتي لهذه المشكلة ، لا يبدو أنها كذلك خيار.

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

هناك خيار آخر يتمثل في تعطيل التحميلات متعددة الأجزاء واستخدام # 575 - سنرى توفيرًا ضخمًا على الفور.

لقد وجدت المشكلة العكسية. لقد غيرت ملفًا في S3 له نفس الحجم ولكن الطابع الزمني الأحدث ومزامنة s3 لا يسحبه

aws s3 sync s3: // bucket / path / dir

بالنظر إلى البيانات في S3 ... أعتقد أن ذلك بسبب مشكلات المنطقة الزمنية.
تظهر الخصائص وقت

آخر تعديل: 21/2/2014 10:50:33 ص

لكن رؤوس HTTP تظهر

آخر تعديل: الجمعة 21 فبراير 2014 15:50:33 بتوقيت جرينتش

لاحظ أن خاصية Last Modified لا تُظهر المنطقة الزمنية؟

نظرًا لأن أمر s3 sync الخاص بي يعمل على خادم مختلف بمنطقة زمنية مختلفة من حيث أضع الملف ، فإنه يعتقد أن الملف في الماضي ولا يسحبه.

اضطررت إلى التغيير إلى s3 cp للتأكد من أنه يحصل على جميع الملفات

أعتقد أنه كخطوة أولى ، يجب أن نطبق الوسيطة --size-only . إنه لا يحل المشكلة في الحالة العامة ، ولكن بالنسبة لسيناريوهات معينة ، سيساعد ذلك ويسهل فهمه / شرحه ، لا سيما حالة الاستخدام المشار إليها أعلاه مع المواقع الثابتة التي تتم مزامنتها مع s3.

أعتقد أنه يجب أن يكون للمزامنة خيار لمزامنة الملفات دائمًا إذا كان الملف المراد مزامنته أحدث من الهدف. نقوم بمزامنة الملفات من الجهاز A إلى S3 وبعد ذلك من S3 إلى الجهاز B. إذا لم يتغير حجم الملف (لكن المحتوى يتغير) ، فلن يصل هذا الملف إلى الجهاز B. هذا السلوك معطل. أنا لا أقوم بمزامنة الكثير من الملفات ولكن لا يجب ترك الملفات التي تم تغييرها.

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

jamesls بالإضافة إلى

jamesls هل يجب --size-only et al في 1.3.6؟

يقول ممثل AWS Support الخاص بي للحالة 186692581 أنه أعاد توجيه اقتراحي بعد ذلك إليك.
اعتقدت أنني سأقوم بنشره هنا على أي حال للتعليق:

أعتقد أن الحل البسيط هو إدخال عامل الزغب.
إذا لم يستغرق الأمر أكثر من 5 دقائق للنسخة المحلية -> نسخة S3 ،
ثم استخدم عامل الزغب لمدة 10 دقائق في مقارنات الوقت اللاحقة.
تعامل مع الأوقات النسبية في غضون 10 دقائق على قدم المساواة.
إذا كان وقت S3 أحدث بأكثر من 10 دقائق ، فحينئذٍ قم بالمزامنة من S3 -> محلي.
ربما تضيف "--fuzz = 10m" كخيار.

تضمين التغريدة
ألن يكون https://github.com/aws/aws-cli/pull/575 خيارًا جيدًا على الأقل للملفات التي تم تحميلها من جزء واحد؟

إذا قمت بالتحقق من تنسيق ETAG للملف على S3 ، فقد تختلف فيما إذا تم تحميل الملف كملف فردي ("ETAG =" MD5 Hash ") أو متعدد الأجزاء (ETAG =" MD5 Hash "-" عدد الأجزاء "). لذلك أنت يمكن مقارنة جميع الملفات MD5 المحلية بملف ETAG الخاص بهم وفي حالة تحميل ملف كملف متعدد الأجزاء ، يمكنك تخطيه.

لدينا عميل لديه الكثير من مقاطع الفيديو في مجلدات معينة على حاوية S3 ، والتي تتم مزامنتها مع مثيلات ec2 في جميع مناطق AWS. يتم تحميل جميع الملفات كجزء واحد.
في الوقت الحالي لدينا مشكلة بسبب s3cmd ، أن بعض الملفات تالفة في بعض الحالات. إذا أردنا إجراء مزامنة كاملة مرة أخرى ، فسيتم تحصيل 14 تيرابايت من حركة المرور.

مشكلتنا: الملفات التالفة لها نفس الحجم تمامًا مثل الملف الأصلي في s3 وبسبب الطوابع الزمنية الخاطئة عبر s3cmd لا يمكننا استخدام الخيارات المذكورة أعلاه. في هذه الحالة ، سيكون --compare-on-etag حلاً رائعًا لمنع مزامنة جميع الملفات مرة أخرى.

حتى بالنسبة للمزامنة العادية ، سيكون الخيار --compare-on-etag رائعًا ، إذا كان لديك جزء واحد فقط من الملفات التي تم تحميلها ، لأن aws s3 sync لن يقوم إلا بمزامنة الملفات التي تم تغييرها.

لقد أمضيت للتو الجزء الأفضل من 3 ساعات في محاولة للعثور على الحد الأدنى من الأذونات المطلوبة لاستخدام أمر المزامنة. الخطأ الذي كنت أواجهه هو:
A client error (AccessDenied) occurred when calling the ListObjects operation: Access Denied

عندما كان يجب أن يكون الخطأ حقًا:
A client error (AccessDenied) occurred when calling the ListBucket operation: Access Denied

عنصر المساعدة الذي يعرض جدولاً به الحد الأدنى من الأذونات لكل أمر سيكون مفيدًا جدًا.

404 تبدو فكرة جيدة حقًا ، مع ملاحظة ذلك حتى قرأت أنني اعتقدت أن المزامنة فعلت ذلك بالفعل.

تحرير: للتوضيح ، أضف rsync like السلوك إلى "aws s3 sync". يبدو أن هذه المشكلة كما تم الإبلاغ عنها ليست تمامًا كما فهمتها في البداية.

نظرًا لأن أحدث إصدار من AWS-CLI-bundle.zip لا يحتوي على الإصلاح المطبق أعلاه ، فقد قمت باستنساخ git. يمكنني رؤية الرمز الجديد في مجلد يسمى "التخصيصات". ومع ذلك ، ليس من الواضح بالنسبة لي كيفية إنشاء أمر aws-cli باستخدام هذا الرمز. هل يجب علي تشغيل Make-bundle؟

نعم. أستخدم الخطوات التالية لتثبيته على خوادم جديدة (أوبونتو):

git clone https://github.com/andrew512/aws-cli.git
cd aws-cli
pip install -r requirements.txt
sudo python setup.py install

نعم.
أرى الكود المعدل في الإصدار 1.3.18.
إنه يقبل معلمة --exact-timestamps.
اعتقدت أن أحدث حزمة تنزيل قمت بتثبيتها مسبقًا كانت 1.3.21.

لن يتم تطبيق الإصدار الموثوق به إلا على إصدارات AWS الرسمية. لقد قمت بتقسيم الريبو عند 1.3.18 ، لذلك هذا هو الإصدار الذي سيعلن عنه ، لكنه بالفعل إصدارات قليلة قديمة ، مع 1.3.22 هو الأحدث حتى الآن. نأمل أن تقبل AWS طلب السحب وتضمين الميزة في الإصدارات الرسمية المستقبلية. لقد كان ذا قيمة كبيرة بالنسبة لنا ويساعد في معالجة سلوك افتراضي مشكوك فيه إلى حد كبير.

@ andrew512 آسف على التأخير. أعتقد أن العلاقات العامة الذي أرسلته قد هو فكرة جيدة، وأنه من المفيد حقا أن يكون ملاحظات العملاء فيما يتعلق بما aws s3 sync يغير عمل لهم وماذا لا يفعلون ذلك. سألقي نظرة بعد قليل.

أعتقد ... بالنسبة لأولئك منا الذين لا يمانعون في طلبات الرأس ، يجب أن تكون المقارنة على MD5 خيارًا. سأقوم (ثانيًا) بالتصويت لـ --compare-on-etag لأنني أقوم بالتحديث فقط من خادم واحد إلى S3 - وبالتالي لا يمثل إعادة شراء MD5 المحلي مشكلة بالنسبة لي. لكنني أعتقد بالتأكيد أننا بحاجة إلى شيء ما. كما هي ، لست متأكدًا أبدًا من أن مستودعاتي المحلية و S3 هي نفسها. أين نحن من حالة شيء كهذا؟

janngobble +1

حالة الاستخدام لدينا هي أن لدينا هذه الملفات في git repo وهي ملفات تكوين لذا لا يعمل التاريخ المعدل ولا حجم الملف حقًا لذلك نود أن نرى خيار md5 الفعلي لأولئك الذين يمكنهم التعامل مع آثار الأداء.

هذا لأنه عندما تقوم بسحب git repo ، يكون تاريخ تعديل الملف هو وقت كتابة الملف. أيضًا حجم الملف لا يعمل لأن تغيير الملف قد يكون شيئًا مثل:

foo="bar"

إلى

foo="baz"

لذلك لن يتغير حجم الملف.

jamesls لماذا لا يمكنك استخدام الطريقة هنا لحساب md5 لعمليات التحميل متعددة الأجزاء؟ عملت معي.

أهلا،
لدي أيضًا وصف لهذه المشكلة بشكل جيد مع foo = "bar" / foo = "baz".
أستخدم حاوية S3 لنشر تطبيقي ومزامنة جميع الخوادم من S3 عند الانتهاء من النشر. واجهت مشكلة عامل التشغيل عدة مرات> = تغيرت إلى <= في ملف لم تتم مزامنته بسبب هذا الخطأ وبالنسبة لي ، فإن أمر المزامنة ليس موثوقًا للغاية بسبب هذا الخطأ. الحجم هو نفسه ولكن المحتوى مختلف ، يجب مزامنة الملف.
ليس لدي أي نصيحة خاصة حول كيفية القيام بذلك ، آسف لذلك ، لكنني فقط أعرض حالة الاستخدام الخاصة بي :)

اذهب الرقم ، لقد واجهت نفس المشكلة أثناء تطوير node-ftpsync. افترضت أن AWS سيكون لديها بعض الحلول السحرية لحل هذه المشكلة.

1. تمتص لكنها ضرورية. مقارنة mtime.equals هي أسرع / أقذر طريقة لاكتشاف التغيير. لسوء الحظ ، يجب تطبيع أوقات الساعات بين المضيفين المحليين والبعيدين قبل أن تتم مقارنتها.

من المحتمل أن تكون فكرة جيدة أن "تزعجها" (أي التقريب إلى أقرب 10 دقائق) مثل ngbranitsky الذي اقترحه. يعد القيام بذلك في node.js أمرًا مزعجًا ولكن في Python يجب أن يكون سهلاً مثل اقتطاع البتات القليلة الأخيرة باستخدام طريقة AND.

1. قد يعمل ، مع الآثار الجانبية. لقد استكشفت هذا الخيار أيضًا عن طريق تغيير mtime المحلي لمطابقة قيمة MDTM للخادم (أي FTP mtime). لسوء الحظ ، نادرًا ما تكون تطبيقات خادم FTP متوافقة مع RFC وقد لا تتضمن MDTM. مثال على ذلك ، تمتص مزامنة الملفات عبر FTP لأنه لا يوجد ضمان على اكتمال كل من العميل والخادم.

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

1. هو الخيار الأفضل إذا كنت لا تأخذ في الاعتبار التكلفة. تستدعي مكالمات API الإضافية تكلفة على المستخدمين (أي كما هو الحال في التكلفة المالية). سيكون MD5 ضروريًا فقط لإضافات الملفات والملفات التي تم تغييرها ولكن بالنسبة للمستخدمين الذين يقومون بتخزين الكثير من الملفات الصغيرة و / أو الملفات التي تتغير بشكل متكرر ، يمكن أن تضيف ما يصل.
2. هو الخيار الأفضل إلى حد بعيد لضمان الاتساق ولكنه أيضًا أكبر ألم يجب تنفيذه.

أدرك أن هذا ليس حلاً عامًا ، ولكن سيكون من الجيد جدًا رؤية السلوك الاختياري التالي للمزامنة ، imo. إنه نوع من مثل لا. 4 في OP ، تم تعديله فقط لتحسين الأداء.

1. يتم الاحتفاظ بذاكرة تخزين مؤقت محلية من etags لنظام الملفات المحلي ، ويمكن للمستخدم ، اختياريًا ، ضمان عدم وجود تغييرات خارج النطاق للملفات الموجودة في الحاوية.
2. عند مزامنة local-> server ، يتم استخدام أول تمرير باستخدام mtime / size مقارنة بذاكرة التخزين المؤقت DB لتحديد التغييرات المحتملة في الملفات المحلية. (يتم إجراء ذلك لتجنب إعادة حساب md5 دون داع وهو مكلف بالنسبة إلى fstat.)
3. بالنسبة للمجموعة التي يحتمل تغييرها ، تتم إعادة حساب md5-> etag. إذا كان الملف مختلفًا بالفعل ، فسيتم تحميله. يتم تحديث قاعدة بيانات ذاكرة التخزين المؤقت المحلية في أي حال لمنع إعادة حساب md5 على الملفات المحلية.

حالة الاستخدام هنا هي مزامنة مربعات خرائط الويب ، والتي تتغير عادة بنسبة <1٪ على أساس يومي. الاستثناء هو عندما تحدث عمليات الحذف في البيانات المصدر التي تغير التغطية المكانية للبلاطات ، مما يستلزم إعادة إنشاء المجموعة الكاملة من مربعات الخرائط.

القضية هي الحجم الهائل الذي ينطوي عليه الأمر. أرى مناقشة حول التحميلات الكبيرة متعددة الأجزاء كحالة استخدام ، ولكن ليس حول العديد من الملفات الصغيرة الفردية. كم العدد؟ لدينا حوالي 2 مليون حاليًا ، لكن يمكن أن يزداد الأمر سوءًا. على سبيل المثال ، عند مستوى التكبير / التصغير 16 ، يحتوي العالم على 1 << 16 × 1 << 16 أو 65536 × 65536 قطعة ، أو ~ 4 ب.

الخيارات الحالية هي:

1. مزامنة مع aws-cli بشكل طبيعي ، وإعادة تحميل كل شيء.
   
   
   
   1. هذا هو الأسرع بشكل عام.
   
   
   2. للأسف ، ستحدث العديد من التحميلات غير الضرورية.
   
   
2. مزامنة مع s3cmd ، والذي يستخدم md5 (etag) بدلاً من mtimes. لسوء الحظ:
   
   
   
   1. يقوم دائمًا بإعادة حساب md5 لكل ملف محلي في كل مرة يتم تشغيله فيها ، وهو أمر مكلف نسبيًا ويحتوي على الكثير من IOPS.
   
   
   2. إنه مترابط فردي ومقيد بالذاكرة ، وعلى الرغم من بطئه دائمًا ، إلا أنه بطيء بشكل خاص في تحميل العديد من الملفات الفردية ، لا سيما في حالات الكمون العالي لمناطق S3 الأخرى.
   
   

يمكنني كتابة رمز C دون صعوبة كبيرة من شأنه أن يمشي في مسار الدليل ، وتحديث قاعدة بيانات ذاكرة التخزين المؤقت المحلية لـ sqlite3 ، وبناء قائمة انتظار المجموعة / التحميل التي يحتمل تغييرها. لسوء الحظ ، ليس لدي أي خبرة في لغة python ولا يمكنني إرسال هذا كطلب سحب لسلوك مزامنة اختياري.

لا أعرف مدى شيوع حالة استخدام "العديد من الملفات الصغيرة ، التي تضمن عدم وجود تغييرات خارج النطاق ، المحلي> الخادم فقط".

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

تتعلق أيضًا بـ # 404.

ماذا عن إضافة علامة --sync-if ذاتية التوثيق بدلاً من العدد المتزايد لخيارات التوثيق غير الذاتي؟ (على سبيل المثال ، --size-only ، --exact-timestamps . هل يمكنني تطبيق هذين الاثنين في نفس الوقت؟ لماذا يجب علي قراءة الوثائق / تجربتهم لمعرفة ذلك؟).

يمكن أن يحتوي --sync-if على قائمة من الخيارات:

--sync-if newer-timestamp,different-md5,different-timestamp,different-size,deleted,...

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

سيوضح هذا السلوك بشكل كبير ، خاصة إذا ذكرت في الوثائق أن السلوك الافتراضي هو: --sync-if different-timestamp,different-size .

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

أريد شيئًا يعمل ببساطة مثل rsync -avz لمزامنة التصميم المحلي الخاص بي مع تلك الموجودة على الخادم.

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

ثم بدأت في استخدام --size-only لتسريع العملية. لسوء الحظ ، هذا الشيء لي مؤخرًا. لقد أعدت تسمية ملف ، وتتضمن خطوة الإنشاء قائمة بالملفات الموجودة في ملف service-worker.js حتى يعرف sw ما يجب تخزينه مؤقتًا. لسوء الحظ ، كان اسم الملف القديم والجديد بنفس الطول ، لذلك لم يتم تحديث ملف service-worker.js واستمر في إعطاء 404 لاسم الملف القديم. لقد استغرق الأمر بعض الوقت لمعرفة ما كان يجري.

يبدو أن هذه مشكلة تم حلها في بيئات أخرى - على سبيل المثال عن طريق rsync - على الرغم من ، tbh ، ربما أكون جاهلاً نوعًا ما بالتحديات التي يواجهها القيام بشيء مثل هذا على S3. على أي حال ، بعد أن تعرضت لهذا الأمر مؤخرًا ، فأنا أبحث عن عملاء آخرين ، لكن يبدو أن لديهم تبعيات لست مهتمًا باعتمادها لهذه الوظيفة فقط.

سيكون من الرائع أن يكون لديك خيار مزامنة etag. أعلم أن هناك سيناريوهات تفشل فيها ، لكن بالنسبة لي ستكون ذات قيمة فائقة.

صباح الخير!

نحن نغلق هذه المشكلة هنا على GitHub ، كجزء من ترحيلنا إلى

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

ككتاب تمهيدي سريع لـ UserVoice (إن لم يكن مألوفًا بالفعل): بعد نشر الفكرة ، يمكن للأشخاص التصويت على الأفكار ، وسيستجيب فريق المنتج مباشرةً للاقتراحات الأكثر شيوعًا.

لقد قمنا باستيراد طلبات الميزات الحالية من GitHub - ابحث عن هذه المشكلة هناك!

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

سيظل GitHub هو القناة للإبلاغ عن الأخطاء.

مرة أخرى ، يمكن الآن العثور على هذه المشكلة من خلال البحث عن العنوان على: https://aws.uservoice.com/forums/598381-aws-command-line-interface

-فريق أدوات وأدوات AWS SDK

يمكن العثور على هذا الإدخال على وجه التحديد في UserVoice على: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168808-aws-s3-sync-issues

https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168808-aws-s3-sync-issues

الابتعاد عن قضايا جيثب؟ يبدو أن هذا خطأ ...

متفق. يبدو الأمر أشبه بالطريقة التي تستخدمها Microsoft للحكم على أهمية / تأثير المشكلات ، لكنني أجدها مزعجة للغاية.

بناءً على تعليقات المجتمع ، قررنا إعادة طلبات الميزات إلى مشكلات GitHub.

ارتطام هذا النسخ الاحتياطي!

الى القمة!

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

jamesls هل يمكنك التعليق على هذا الموضوع من فضلك؟
https://github.com/aws/aws-cli/issues/4460