Aws-cli: AWS S3 सिंक सभी फाइलों को सिंक नहीं करता है

इसके समाधान के लिए आप संभवतः --exact-timestamps का उपयोग कर सकते हैं, हालांकि यदि आप अपलोड कर रहे हैं तो इसके परिणामस्वरूप अतिरिक्त अपलोड हो सकते हैं।

पुनरुत्पादन में सहायता के लिए, क्या आप मुझे उन फ़ाइलों में से एक के बारे में कुछ जानकारी प्राप्त कर सकते हैं जो समन्वयित नहीं हो रही हैं?

• स्थानीय रूप से सटीक फ़ाइल आकार क्या है?
• S3 में सटीक फ़ाइल आकार क्या है?
• स्थानीय रूप से अंतिम संशोधित समय क्या है?
• S3 में अंतिम संशोधित समय क्या है?
• क्या स्थानीय फ़ाइल एक सिम्लिंक/एक सिम्लिंक के पीछे है?

उदाहरण कमांड रन
aws s3 सिंक s3://bucket/ /var/www/folder/ --delete

कई फाइलें गायब हैं
सटीक स्थानीय आकार: 2625
सटीक s3: 2625
सटीक समय टिकट स्थानीय: 06-जनवरी-2017 9:32:31
सटीक समय टिकट s3: 20-जून-2017 10:14:57
S3 और स्थानीय में सामान्य फ़ाइल

करीब 50,000 फाइलों की सूची में ऐसे कई मामले हैं। हालांकि सभी लापता 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 सिंक}} कमांड ने इसे अपलोड नहीं किया। मेरा "वर्कअराउंड" S3 से index.html को हटाना था, और फिर सिंक को फिर से चलाना था (जिसने इसे अपलोड किया जैसे कि यह एक नई फ़ाइल थी, मुझे लगता है)।

सर्वर: 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 270T से अधिक डेटा चलने के बाद मैंने कुछ GB फ़ाइलें खो दीं। सिंक ने विशेष वर्णों वाली फ़ाइलों को बिल्कुल भी कॉपी नहीं किया।

फ़ाइल का उदाहरण /data/company/storage/projects/1013815/3.Company Estimates/B. Estimates

cp -R -n का उपयोग करना पड़ा

एक ही समस्या यहाँ एक ही आकार की xml फ़ाइल है लेकिन अलग-अलग टाइमस्टैम्प सही ढंग से समन्वयित नहीं है

मैं इस मुद्दे को पुन: पेश करने में सक्षम था

Bug.tar.gz
संलग्न टार फ़ाइल डाउनलोड करें और फिर

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

आप देखेंगे कि भले ही निर्देशिका a और b में repomd.xml सामग्री और टाइमस्टैम्प में भिन्न हो
b को सिंक करने का प्रयास कुछ भी नहीं करता है

पर परीक्षण किया गया
एडब्ल्यूएस-क्ली/1.16.88 पायथन/2.7.15 डार्विन/16.7.0 बोटोकोर/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 जोड़ा और समस्या दोबारा नहीं हुई। लेकिन, यह पहली बार में रुक-रुक कर था इसलिए मुझे यकीन नहीं हो रहा है कि इसे ठीक कर दिया गया है। अगर ऐसा दोबारा होता है तो मैं @marns93 के सुझाव के साथ

हम इस समस्या का सामना कर चुके हैं और --exact-timestamps हमारी समस्या का समाधान करता है। मुझे यकीन नहीं है कि यह बिल्कुल वही समस्या है।

मैं इस मुद्दे को देख रहा हूं, और यह बहुत स्पष्ट है क्योंकि प्रत्येक कॉल को केवल एक मुट्ठी भर (एक दर्जन से कम) फाइलों की प्रतिलिपि बनाना है।

जिस स्थिति में यह होता है, वह ऊपर बताए गए अनुसार होता है: यदि फ़ोल्डर में sync एड किया जा रहा है जिसमें विभिन्न फ़ाइल सामग्री वाली फ़ाइल है लेकिन समान फ़ाइल आकार है, तो sync नई अपडेट की गई फ़ाइल की प्रतिलिपि बनाना छोड़ देगा एस3.

हमने इसे ठीक करने के लिए स्क्रिप्ट को aws s3 cp --recursive बदलना समाप्त कर दिया, लेकिन यह एक बुरा बग है - सबसे लंबे समय तक हमने सोचा कि हमारे अपने आवेदन में किसी प्रकार की दौड़ की स्थिति थी, यह महसूस नहीं कर रहा था कि aws-cli बस था अद्यतन की गई फ़ाइल(फ़ाइलों) की प्रतिलिपि नहीं बनाना चुनना।

मैंने इसे एक html फ़ाइल के साथ भी देखा

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

मैंने GitHub जिस्ट से s3 sync कमांड को कॉपी पेस्ट किया और उस पर --size-only सेट था। इसे हटाने से समस्या ठीक हो गई!

बस इस मुद्दे में एक बाल्टी पर अपलोड की जा रही कलाकृतियों के साथ भाग गया। हमारा HTML केवल एसेट लिंक के लिए हैश कोड बदलने की प्रवृत्ति रखता था और इसलिए आकार हमेशा समान था। S3 सिंक इन्हें छोड़ रहा था यदि बिल्ड पिछले एक के तुरंत बाद था। उदाहरण:

10:01 - 1 रन बनाएं
10:05 - 2 रन बनाएं
10:06 - बिल्ड 1 को s3 . पर अपलोड किया गया है
10:10 - बिल्ड 2 को s3 . पर अपलोड किया गया है

बिल्ड 2 में 10:05 के टाइमस्टैम्प के साथ एचटीएमएल फाइलें हैं, हालांकि एस3 पर बिल्ड 1 द्वारा अपलोड की गई एचटीएमएल फाइलों में 10:06 का टाइमस्टैम्प है, जब ऑब्जेक्ट बनाए गए थे। इसके परिणामस्वरूप उन्हें s3 सिंक द्वारा अनदेखा किया जा रहा है क्योंकि दूरस्थ फ़ाइलें स्थानीय फ़ाइलों की तुलना में "नई" हैं।

जैसा कि पहले सुझाया गया था, मैं अब s3 cp --recursive बाद s3 sync --delete का उपयोग कर रहा हूं।

आशा है कि यह किसी के लिए सहायक हो सकता है।

इस सप्ताह की शुरुआत में मेरा भी यही मुद्दा था; मैं --size-only का उपयोग नहीं कर रहा था। हमारे index.html एक वर्ण अलग था ( . के लिए चला गया # ,) इसलिए आकार एक ही था, लेकिन S3 पर टाइमस्टैम्प नए सूचकांक के टाइमस्टैम्प 40 मिनट से पहले था .एचटीएमएल। मैंने index.html को अस्थायी समाधान के रूप में हटा दिया है, लेकिन प्रत्येक परिनियोजन की दोबारा जांच करना संभव नहीं है।

यहां वही, एक ही नाम वाली फाइलें लेकिन अलग-अलग टाइमस्टैम्प और सामग्री के साथ S3 से स्थानीय में सिंक नहीं किया जाता है और --delete मदद नहीं करता है

हम एक ही मुद्दे का अनुभव करते हैं। समान आकार वाला लेकिन नया टाइमस्टैम्प वाला index.html कॉपी नहीं किया जाता है।

यह मामला एक साल पहले बताया गया था। यह तय क्यों नहीं है?

दरअसल यह snyc कमांड को बेकार कर देता है।

सही समय

--सटीक-टाइमस्टैम्प ने समस्या को ठीक कर दिया

मैं भी इस मुद्दे से प्रभावित हूं। मैंने --exact-timestamps जोड़ा और समस्या उन फ़ाइलों को ठीक करने के लिए लग रही थी जिन्हें मैं देख रहा था। मैंने पूरी खोज नहीं की है। मेरे पास 100k फाइलें और 20 जीबी का ऑर्डर है, जो यहां के अन्य लोगों की तुलना में बहुत कम है।

मुझे एक ही समस्या का सामना करना पड़ा है, aws s3 sync कुछ फ़ाइलों को छोड़ दें, यहां तक ​​​​कि विभिन्न सामग्रियों और अलग-अलग तिथियों के साथ भी। लॉग दिखाता है कि उन छोड़ी गई फ़ाइलों को समन्वयित किया गया है लेकिन वास्तव में नहीं।
लेकिन जब मैं फिर से aws s3 sync चलाता हूं, तो वे फ़ाइलें समन्वयित हो जाती हैं। बहुत अजीब!

ह्यूगो के साथ साइट बनाते समय मुझे यह समस्या थी और मैंने आखिरकार इसका पता लगा लिया। मैं अपने ह्यूगो थीम के लिए सबमॉड्यूल का उपयोग करता हूं और उन्हें सीआई पर नीचे नहीं खींच रहा था। यह ह्यूगो में चेतावनियां पैदा कर रहा था लेकिन विफलताएं नहीं।

# 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  

एक बार जब मैंने सबमॉड्यूल को अपडेट कर दिया तो सब कुछ उम्मीद के मुताबिक काम कर गया।

हम भी इस मुद्दे से प्रभावित हुए हैं, इतना अधिक कि एक नई vendor/autoload.php फ़ाइल के सिंक नहीं होने के बाद एक प्लेटफ़ॉर्म ~18 घंटों के लिए नीचे चला गया, और vendor/composer/autoload_real.php साथ पुराना हो गया था इसलिए पूरा ऐप लोड नहीं हो सका।

यह एक बहुत ही अजीब समस्या है, और मुझे विश्वास नहीं हो रहा है कि यह मुद्दा इतने लंबे समय से खुला है।

एक सिंक अंतिम संशोधित के बजाय हैश का उपयोग क्यों नहीं करेगा? 0 समझ में आता है।

भविष्य के Googlers के लिए, एक संशोधित त्रुटि जो मुझे मिल रही थी:

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 कॉपी की जाती है, तो उसे बकेट पर प्राप्त होने वाला टाइमस्टैम्प वह तारीख होती है, जिसकी उसे कॉपी की गई थी, जो कि स्रोत फ़ाइल की तारीख से _always_ नई होती है। इस तरह s3 काम करता है।
• फ़ाइलें केवल तभी समन्वयित की जाती हैं जब आकार बदलता है, या लक्ष्य पर टाइमस्टैम्प स्रोत से _older_ है।
• इसका अर्थ यह है कि यदि स्रोत फ़ाइलों को अद्यतन किया जाता है, लेकिन फ़ाइलों का आकार अपरिवर्तित रहता है और उन परिवर्तित फ़ाइलों की तिथियां पिछली बार कॉपी किए जाने पर पूर्व-तारीख होती हैं, तो s3 सिंक उन्हें फिर से सिंक नहीं करेगा।
• s3 से लोकल में कॉपी करते समय --exact-timestamps _only_ का उपयोग करना काम करता है। यह जानबूझकर स्थानीय के लिए s3 के लिए सक्षम नहीं है क्योंकि टाइमस्टैम्प _never_ बराबर हैं। इसलिए स्थानीय से s3 में समन्वयित करते समय इसे सेट करने से कोई प्रभाव नहीं पड़ता है।
• मुझे नहीं लगता कि s3 अपलोड की गई फ़ाइलों के लिए हैश की गणना करता है, इसलिए फ़ाइल आकार और अंतिम अपलोड तिथि को चेक के रूप में टालने का कोई तरीका नहीं है।

लब्बोलुआब यह है कि यह इरादा के अनुसार काम करता है, लेकिन ऐसे कई उपयोग के मामले हैं जहां यह वांछनीय नहीं है। जैसा कि ऊपर उल्लेख किया s3 cp --recursive का उपयोग करके इसके आसपास काम किया है

@ जैम 13 स्पष्टीकरण के लिए धन्यवाद, अब यह सब समझ में आता है!

फिर भी, मैं तर्क दूंगा कि यह वर्तमान में खराब दस्तावेज है (मुझे दस्तावेज़ीकरण में एक मोटी लाल चेतावनी की उम्मीद होगी कि --exact-timestamps केवल _from s3 से local_ तक काम करता है और s3 cli के लिए चुपचाप के बजाय सिर्फ जमानत के लिए काम करता है पैरामीटर को अनदेखा करना) और एक वैकल्पिक हैश-आधारित तुलना मोड मज़बूती से काम करने वाले सिंक्रनाइज़ेशन मोड को लागू करने के लिए आवश्यक है।

हां, दस्तावेज़ीकरण बहुत अच्छा नहीं है, और चुपचाप विकल्पों को अनदेखा करना बहुत ही अनुपयोगी है। पिछले 2 वर्षों में एडब्ल्यूएस की ओर से इस टिकट पर किसी भी प्रबंधन या यहां तक ​​कि आधिकारिक टिप्पणियों की अनुपस्थिति भी बहुत कुछ कहती है।

@ Jam13 मैंने कुछ दस्तावेज़ों में खुदाई की, और पता चला कि मुझे s3 से स्थानीय तक कुछ मुद्दों को रोकने के लिए --exact-timestamps की आवश्यकता है। धन्यवाद!

@kyleknap @KaibaLopez @stealthycoin इस पर कोई अपडेट?

मुझे विश्वास नहीं हो रहा है कि यह टिकट कुछ समय पहले बंद नहीं हुआ था। जहां तक ​​​​मैं कह सकता हूं, यह डिज़ाइन के रूप में काम करता है, लेकिन उपयोगकर्ता (मेरे सहित) इस बारे में धारणा बनाते हैं कि इसे कैसे काम करना चाहिए और फिर आश्चर्यचकित हो जाते हैं जब यह व्यवहार नहीं करता है कि वे कैसे उम्मीद करते हैं।

* 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 के रूप में

यह शायद इरादे से काम कर रहा है, लेकिन काम नहीं कर रहा है जैसा इसे करना चाहिए। यह जांचना तुच्छ होना चाहिए कि कोई फ़ाइल बदल गई है या नहीं

लोगों को अप्रत्याशित रूप से सिंक से बाहर अनुभव करने के लिए यह सिर्फ एक बड़ा गोचा है
आंकड़े। 100 अलग-अलग वर्कअराउंड हैं जो यहां सभी को बचा सकते हैं
इस टिकट को पढ़ने का समय, साथ ही इसे खोजने में बिताया गया समय
उनके स्रोत कोड में एक मुद्दा था। वे इनमें से एक क्यों नहीं कर सकते?

मंगलवार, 14 अप्रैल, 2020 दोपहर 1:57 बजे कीथ केली सूचनाएं @github.com
लिखा था:

मुझे विश्वास नहीं हो रहा है कि यह टिकट कुछ समय पहले बंद नहीं हुआ था। जहाँ तक मैं यह कर सकता हूँ
बताओ, यह डिजाइन के रूप में काम करता है, लेकिन उपयोगकर्ता (मेरे सहित) धारणा बनाते हैं
इसे कैसे काम करना चाहिए और फिर आश्चर्यचकित हो जाते हैं जब यह व्यवहार नहीं करता कि वे कैसे करते हैं
अपेक्षित होना।

• जब कोई फ़ाइल सिंक की जाती है या _to_ s3 कॉपी की जाती है, तो उसे बकेट पर प्राप्त होने वाला टाइमस्टैम्प वह तारीख होती है, जिसकी उसे कॉपी की गई थी, जो कि स्रोत फ़ाइल की तारीख से _always_ नई होती है। इस तरह s3 काम करता है।

• फ़ाइलें केवल तभी समन्वयित की जाती हैं जब आकार बदलता है, या लक्ष्य पर टाइमस्टैम्प स्रोत से _older_ है।

• इसका अर्थ यह है कि यदि स्रोत फ़ाइलों को अद्यतन किया जाता है, लेकिन फ़ाइलों का आकार अपरिवर्तित रहता है और उन परिवर्तित फ़ाइलों की तिथियां पिछली बार कॉपी किए जाने पर पूर्व-तारीख होती हैं, तो s3 सिंक उन्हें फिर से सिंक नहीं करेगा।

• s3 से लोकल में कॉपी करते समय --exact-timestamps _only_ का उपयोग करना काम करता है। यह जानबूझकर स्थानीय के लिए s3 के लिए सक्षम नहीं है क्योंकि टाइमस्टैम्प _never_ बराबर हैं। इसलिए स्थानीय से s3 में समन्वयित करते समय इसे सेट करने से कोई प्रभाव नहीं पड़ता है।

• मुझे नहीं लगता कि s3 अपलोड की गई फ़ाइलों के लिए हैश की गणना करता है, इसलिए फ़ाइल आकार और अंतिम अपलोड तिथि को चेक के रूप में टालने का कोई तरीका नहीं है।

लब्बोलुआब यह है कि यह इरादा के अनुसार काम करता है, लेकिन विभिन्न उपयोग के मामले हैं
जहां यह वांछनीय नहीं है। जैसा ऊपर उल्लिखित है
<#m_8540343689970969812_issuecomment-534061850> मैंने इसके आसपास काम किया है
s3 cp --recursive . का उपयोग करना

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 साथ भी समस्या हो रही है। मैंने देखा कि एकमात्र कारण यह था कि मैं दोनों सिरों पर एमएचएल को सील और सत्यापित कर रहा था। sync काम नहीं करेगा, और मैं 890 जीबी में से लगभग 60 जीबी खो रहा था, फ़ोल्डर से फ़ोल्डर के माध्यम से जाने की कोशिश कर रहा था। तब मुझे यह धागा मिला और cp --recursive की कोशिश की और डेटा फिर से बहने लगा। बाकी डेटा मिलने के बाद मैं एमएचएल को आखिरी बार सत्यापित करूंगा।

मैंने समस्या को पुन: उत्पन्न करने के लिए एक स्क्रिप्ट लिखी, मैं इसका उपयोग करता हूं:
एडब्ल्यूएस-क्ली/1.18.34 पायथन/2.7.17 डार्विन/19.4.0 बोटोकोर/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 सिंक _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 सिंक अभी भी फ़ाइल डाउनलोड नहीं करता है, इसलिए यह केवल एक समयक्षेत्र मुद्दा नहीं है।

ऊपर दिया गया टच कमांड केवल माइम को बैकडेट करता है। यह 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 ।

https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439 पर स्पष्टीकरण के लिए धन्यवाद