Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sync command copies a new object everytime when the s3 version is on GLACIER #712

Closed
stevenmcastano opened this issue Mar 11, 2024 · 3 comments · Fixed by #734
Closed

sync command copies a new object everytime when the s3 version is on GLACIER #712

stevenmcastano opened this issue Mar 11, 2024 · 3 comments · Fixed by #734
Assignees
Labels

Comments

@stevenmcastano
Copy link

I'm running version v2.2.2-48f7e59 and when I add the --storage-class 'GLACIER' option to my command line, it does properly put the object in Glacier, but then subsequent sync commands fail to detect that version as the same as the one being on disk and subsequent runs just copy a new version over and over again.

This really defeats the purpose for me... I'm trying to upload backups of a large photo library to use as a cloud backup from my NAS. So there is rarely if ever a need to download everything, but I do... at times... update a few files here and there, mostly just adding files to an already existing directory... so this makes it impossible for me to write a script that executes via cron once a night to upload my backups.

@ilkinulas ilkinulas added the sync label Jun 23, 2024
@ilkinulas ilkinulas added this to s5cmd Jun 28, 2024
@ilkinulas ilkinulas moved this to In Progress in s5cmd Jul 5, 2024
@ilkinulas ilkinulas moved this from In Progress to Review in s5cmd Jul 5, 2024
@github-project-automation github-project-automation bot moved this from Review to Done in s5cmd Nov 27, 2024
@jesanfafon
Copy link

Not sure if this is the same issue precisely or not, but I'm still showing files being copied in a --dry-run of sync on 2.3.0 even though they exist in the target s3 bucket. Going to run the command for real and see if the behavior matches --dry-run or not.

@4o4x
Copy link
Contributor

4o4x commented Dec 19, 2024

@jesanfafon
I have tried it several time after your comment. It seems like there is no issue.

Going to run the command for real

Did you run ?

@jesanfafon
Copy link

I have tried it several time after your comment. It seems like there is no issue.

Yes, I ran it again. It worked. I suspect the session I was in had the old executable cached, or there was something subtly wrong with the command I was running.

False alarm!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants