Aws-cli: AWS S3 동기화가 모든 파일을 동기화하지 않음

--exact-timestamps 를 사용하여 이 문제를 해결할 수 있지만 업로드하는 경우 초과 업로드가 발생할 수 있습니다.

재생산을 돕기 위해 동기화되지 않는 파일 중 하나에 대한 정보를 얻을 수 있습니까?

• 로컬에서 정확한 파일 크기는 얼마입니까?
• S3의 정확한 파일 크기는 얼마입니까?
• 로컬에서 마지막으로 수정한 시간은 무엇입니까?
• S3에서 마지막으로 수정된 시간은 무엇입니까?
• 로컬 파일이 심볼릭 링크입니까 / 심볼릭 링크 뒤에 있습니까?

예제 명령 실행
AWS s3 동기화 s3://bucket/ /var/www/folder/ --delete

여러 파일이 누락되었습니다.
정확한 지역 크기: 2625
정확한 s3: 2625
정확한 현지 시간: 2017년 1월 6일 9:32:31
정확한 타임스탬프 s3: 2017년 6월 20일 10:14:57
S3 및 로컬의 일반 파일

약 50,000개의 파일 목록에 이와 같은 경우가 여러 개 있습니다. 그러나 동기화에서 누락된 모든 항목은 2017년 6월 20일 다양한 시간입니다.

--exact-timestamps를 사용하면 완전히 동일한 내용이지만 다운로드할 파일이 훨씬 더 많이 표시됩니다. 그러나 그들은 여전히 ​​위의 예에서 누락되었습니다.

여기에서 같은 문제.
aws s3 sync dist/ s3://bucket --delete 이 dist/index.html과 함께 s3://bucket/index.html을 업로드하지 않았습니다.

dist/index.html과 s3://bucket/index.html은 파일 크기가 같지만 수정 시간이 다릅니다.

실제로 awscli가 파일을 업로드한 경우도 있지만 그렇지 않은 경우도 있습니다.

여기에서도 마찬가지로 --exact-timestamps 는 도움이 되지 않습니다. index.html 는 덮어쓰지 않습니다.

우리는 이 문제가 오늘/지난 주에 양호하다는 것을 경험했습니다. 다시 index.html은 파일 크기는 같지만 내용과 수정 시간이 다릅니다.

아무도 이것에 대한 해결 방법을 알고 있습니까?

나는 방금 이것에 부딪쳤다. @icymind 및 @samdammers가 보고한 것과 동일한 문제: 내 (로컬) index.html 파일의 내용이 변경되었지만 파일 크기는 S3의 이전 사본과 동일했습니다. {{aws s3 sync}} 명령이 업로드하지 않았습니다. 내 "해결 방법"은 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 파일을 다운받은 후

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 동기화를 시도하면 아무 작업도 수행되지 않습니다.

테스트 날짜
aws-cli/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의 파일 디렉토리를 동기화하려고 합니다. 해당 파일은 로컬 디렉토리에서 업데이트되지 않습니다.

저도 이거 보고 있습니다. 제 경우에는 생성된 .js 파일을 참조하는 index.html이 있는 반응 앱입니다. 더 이상 참조되지 않는 오래된 파일을 삭제하기 위해 --delete 옵션과 동기화하고 있습니다. index.html이 업로드되지 않는 경우가 있어 더 이상 존재하지 않는 .js 파일을 가리키는 오래된 index.html이 생성됩니다.

따라서 내 웹사이트가 작동을 멈춥니다!!!

나는 이것이 왜 일어나고 있는지에 대해 현재 단서가 없습니다.

누구든지 아이디어나 해결 방법이 있습니까?

동일한 문제가 있지만 해결 방법을 찾았습니다. 나는 그것이 최선의 방법은 아니지만 작동한다는 것을 압니다.

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

복사가 제대로 작동하는 것 같으므로 먼저 복사한 다음 sync 명령을 사용하여 더 이상 존재하지 않는 파일을 삭제합니다.
문제가 최대한 빨리 해결되기를 바랍니다.

파이프라인에 --exact-timestamps 을 추가했는데 문제가 재발하지 않았습니다. 하지만 처음부터 간헐적으로 발생해서 고쳐졌는지는 확신할 수 없습니다. 다시 그런 일이 생긴다면 @marns93님 의 제안에

우리는 이 문제를 해결했으며 --exact-timestamps 문제를 해결했습니다. 정확히 같은 문제인지 잘 모르겠습니다.

이 문제가 발생하고 있으며 각 호출에서 소수(12개 미만) 파일만 복사하면 되므로 매우 분명합니다.

이 상황이 발생하는 상황은 위에 보고된 것과 같습니다. 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인 HTML 파일이 있지만 빌드 1에 의해 s3에 업로드된 HTML 파일에는 객체가 생성된 시점인 10:06의 타임스탬프가 있습니다. 그 결과 원격 파일이 로컬 파일보다 "최신"이므로 s3 sync에서 무시됩니다.

저는 지금 s3 cp --recursive 다음에 s3 sync --delete 를 앞서 제안한 대로 사용하고 있습니다.

이것이 누군가에게 도움이되기를 바랍니다.

나는 이번 주 초에 같은 문제를 겪었습니다. --size-only 사용하지 않았습니다. index.html은 단일 문자( . 가 # )가 다르기 때문에 크기는 동일하지만 s3의 타임스탬프는 새 인덱스의 타임스탬프보다 40분 빠릅니다. .html. 임시 해결 방법으로 index.html을 삭제했지만 모든 배포를 다시 확인하는 것은 불가능합니다.

여기에서 동일하지만 이름은 같지만 타임스탬프와 콘텐츠가 다른 파일은 S3에서 로컬로 동기화되지 않으며 --delete는 도움이 되지 않습니다.

동일한 문제가 발생합니다. 크기는 같지만 최신 타임스탬프가 있는 index.html은 복사되지 않습니다.

이 문제는 1년 전에 보고되었습니다. 왜 고정되지 않습니까?

실제로 snyc 명령을 쓸모 없게 만듭니다.

정확한 시간

--exact-timestamps가 문제를 해결했습니다.

저도 이 문제의 영향을 받습니다. --exact-timestamps를 추가했는데 문제가 내가 보고 있는 파일을 수정하는 것 같았습니다. 나는 철저한 검색을 하지 않았다. 나는 100k 파일과 20gb 정도를 가지고 있는데, 여기에 있는 다른 것보다 훨씬 적습니다.

동일한 문제에 직면했습니다. 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  

하위 모듈을 업데이트하면 모든 것이 예상대로 작동했습니다.

우리는 또한 이 문제의 영향을 너무 많이 받아 새 vendor/autoload.php 파일이 동기화되지 않은 후 ~18시간 동안 플랫폼이 다운되었고 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

이 티켓이 너무 오래 열려 있다는 것이 믿기지 않습니다 ... 여기에 동일한 문제가 있습니다. Amazon의 고객 집착은 어디에 있습니까?

이 티켓이 얼마 전에 닫히지 않았다는 것이 믿기지 않습니다. 내가 말할 수 있는 한, 그것은 설계된 대로 작동하지만 사용자(저를 포함하여)는 작동 방식에 대해 가정하고 예상대로 작동하지 않을 때 놀랐습니다.

• 파일이 _s3로 동기화되거나 복사될 때 버킷에 수신되는 타임스탬프는 복사된 날짜로, 소스 파일의 날짜보다 _항상_ 최신입니다. 이것이 바로 s3가 작동하는 방식입니다.
• 파일은 크기가 변경되거나 대상의 타임스탬프가 소스보다 _오래된_ 경우에만 동기화됩니다.
• 즉, 소스 파일이 업데이트되었지만 파일 크기가 변경되지 않고 변경된 파일의 날짜가 마지막으로 복사된 날짜보다 이전인 경우 s3 sync는 파일을 다시 동기화하지 않습니다.
• --exact-timestamps _only_ 사용은 s3에서 로컬로 복사할 때 작동합니다. 타임스탬프가 _절대_ 동일하지 않기 때문에 s3에 대한 로컬에 대해 의도적으로 활성화되지 않았습니다. 따라서 로컬에서 s3로 동기화할 때 설정해도 효과가 없습니다.
• s3가 업로드된 파일의 해시를 계산하지 않는다고 생각하므로 파일 크기와 마지막 업로드 날짜를 검사로 피할 방법이 없습니다.

결론은 의도한 대로 작동하지만 이것이 바람직하지 않은 다양한 사용 사례가 있다는 것입니다. 언급 한 바와 같이 위의 나는 그것을 사용하여 주위에 작업 한 s3 cp --recursive

@jam13 설명 감사합니다. 이제 돌이켜보면 모든 것이 이해가 됩니다!

그럼에도 불구하고, 나는 그것이 현재 제대로 문서화되지 않았다고 주장하고 싶습니다 --exact-timestamps 매개변수 무시) 및 선택적 해시 기반 비교 모드는 안정적으로 작동하는 동기화 모드를 구현하는 데 필요합니다.

예, 문서는 훌륭하지 않으며 옵션을 조용히 무시하는 것은 매우 도움이 되지 않습니다. 지난 2년 동안 AWS에서 이 티켓에 대한 관리 또는 공식 언급이 없었다는 점도 많은 것을 말해줍니다.

@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 로 저장합니다. 문제는 ETag가 파일을 업로드할 때 사용된 청크 수와 청크 크기에 따라 달라집니다. 업로더가 아닌 경우 청크 크기를 모를 수 있습니다(그러나 ETag에서 청크 수는 알 수 있음). 왜 이렇게 하는지 모르겠습니다.

이것은 아마도 의도한 대로 작동하지만 제대로 작동하지 않을 것입니다. 파일이 변경되었는지 확인하는 것은 간단해야 합니다.

사람들이 예기치 않게 동기화되지 않는 것을 경험하는 것은 큰 문제입니다.
데이터. 여기 모든 사람을 구할 수 있는 100가지 다른 해결 방법이 있습니다.
이 티켓을 읽는 시간과 이를 발견한 시간
소스 코드의 문제였습니다. 그들은 왜 이것들 중 하나를 할 수 없습니까?

2020년 4월 14일 화요일 오후 1:57 Keith Kelly [email protected]
썼다:

이 티켓이 얼마 전에 닫히지 않았다는 것이 믿기지 않습니다. 내가 할 수 있는 한
말해, 설계된 대로 작동하지만 사용자(저 포함)는
그것이 어떻게 작동해야 하는지 그리고 그들이 어떻게 행동하지 않을 때 놀란다.
예상되는.

• 파일이 _s3로 동기화되거나 복사될 때 버킷에 수신되는 타임스탬프는 복사된 날짜로, 소스 파일의 날짜보다 _항상_ 최신입니다. 이것이 바로 s3가 작동하는 방식입니다.

• 파일은 크기가 변경되거나 대상의 타임스탬프가 소스보다 _오래된_ 경우에만 동기화됩니다.

• 즉, 소스 파일이 업데이트되었지만 파일 크기가 변경되지 않고 변경된 파일의 날짜가 마지막으로 복사된 날짜보다 이전인 경우 s3 sync는 파일을 다시 동기화하지 않습니다.

• --exact-timestamps _only_ 사용은 s3에서 로컬로 복사할 때 작동합니다. 타임스탬프가 _절대_ 동일하지 않기 때문에 s3에 대한 로컬에 대해 의도적으로 활성화되지 않았습니다. 따라서 로컬에서 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에서 청크 수를 얻을 수 있음). NS
왜 이런 식으로 수행되는지 모르겠습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/aws/aws-cli/issues/3273#issuecomment-613677369 또는
구독 취소
https://github.com/notifications/unsubscribe-auth/ADUA4NKJMCUSGTNAAITGPXTRMTE2NANCNFSM4E3JNHPQ
.

>

...톰

같은 문제가있었습니다. 소스 버킷 정책을 다음과 같이 변경하여 해결했습니다.

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

cp --recursive 및 sync 모두에 문제가 있었습니다.
이것으로 모든 것이 해결되었습니다. 잘 작동했어야 하는 두 가지 작업이 있었지만 그렇지 않았습니다. 시도해 보고 문제가 해결되었는지 알려주십시오.

sync 에도 문제가 있음을 알리기 위해 여기까지 왔습니다. 내가 알아차린 유일한 이유는 양쪽 끝에서 MHL 을 봉인하고 확인했기 때문입니다. sync 가 작동하지 않고 폴더별로 890GB 중 약 60GB가 누락되었습니다. 그런 다음 이 스레드를 찾아 cp --recursive 시도했고 데이터가 다시 흐르기 시작했습니다. 이 데이터의 나머지 부분을 얻으면 마지막으로 MHL을 확인하겠습니다.

문제를 재현하기 위해 스크립트를 작성했으며 다음을 사용합니다.
aws-cli/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 sync는 여전히 파일을 다운로드하지 않으므로 단순히 시간대 문제가 아닙니다.

수정 시간을 지금으로 변경하면(로컬 파일이 원격 파일보다 최신 파일이 됨) s3 sync가 파일을 다운로드 _하지_ 않습니다!

나는 그것을 이해할 수 없었으므로 문서를 확인했습니다. 상태( --exact-timestamps 옵션을 설명할 때):

기본 동작은 로컬 버전이 S3 버전보다 최신 버전이 아닌 경우 동일한 크기의 항목을 무시하는 것입니다.

다운로드에 --exact-timestamps 를 사용하면 예상대로 작동하지만(타임스탬프의 차이로 인해 복사본이 생성됨) 이 기본값은 거꾸로 보입니다.

아마도 "설계된 대로 작동한다"라고 말하는 대신 "문서화된 대로 작동한다"라고 말해야 할 것입니다.

@jam13 우와 너무 이상하고 설명서에 혼동이 있는 줄 알았어요!
그러나 이것이 버그를 수정하는 새로운 방법이라면 문서에 명시적으로 삽입하여 ...

@jam13

시간대 문제를 배제할 수 있는지 확실하지 않습니다.
매일 s3 콘솔에서 첫 번째 변경을 수행하고 aws s3 sync s3://$BUCKET . 동기화하면 동기화됩니다. 파일을 변경한 다음 동기화하면 동기화되지 않습니다.
그러나 그것은 다음날 작동합니다.

이것은 시간대 때문일 수 있는지 다시 생각하게 합니다.

그래서 위에서 언급한 touch -m 명령에 대해 조금 더 확인했습니다.

touch -m -t 201901010000 test/local/test.json
파일 수정 시간을 작년으로 변경해도 s3 sync는 여전히 파일을 다운로드하지 않으므로 단순히 시간대 문제가 아닙니다.

위의 touch 명령은 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 .

https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439에서 설명을 해주신 @jam13 에게 감사드립니다.