-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
aws s3 exclude / include commands ignored #434
Comments
the
...and here's some of the dry run output.
|
The same occurs with $ aws --version
aws-cli/1.2.6 Python/2.7.5 Darwin/12.5.0
$ tree test
test
├── a.jpg
├── b.png
└── c.jpg
0 directories, 3 files
$ aws s3 sync test s3://my-bucket/test --include "*.png" --dryrun
(dryrun) upload: test/a.jpg to s3://my-bucket/test/a.jpg
(dryrun) upload: test/b.png to s3://my-bucket/test/b.png
(dryrun) upload: test/c.jpg to s3://my-bucket/test/c.jpg |
👍 |
+1 Just bitten by this nasty bug. Please fix. |
Just got bit by this one too. It's a shame it's documented but not working. Not running Windows either. |
There's two issues being discussed here. The first is a windows specific issue. The other comments here appears to be about |
Thanks for your comment Jamesis, I actually thought that might be how it worked but I tried the following with no joy:
|
So, shouldn't this work?
|
@danieljimenez I believe you're running into #531 which should be fixed in the latest version (currently 1.2.7). There was a bug in earlier versions that required the bucket name to be included for include/exclude filters for s3 locations, which is inconsistent with how local file include/exclude works. This has now been fixed and you're example should work on the latest version. Debug logs have also been added to help troubleshoot include/exclude issues. For example, running with the
So in this example, we can see that the pattern "bucket-name/foo.png" matched the exclude filter "bucket-name/foo*" and Hope that clarifies things, I'll get the docs updated to better explain this. |
I can confirm that the windows issue originally mentioned is still an issue. This appears to be because we are including the drive name as part of the filter on windows:
Looking into a fix. |
This is now fixed in #554 and will go out in the next release. |
I still experience this with rm on |
|
me too, only
|
Exclude doesn't seem to be working properly when attempting to sync from local to s3: aws-cli/1.10.67 Python/2.7.6 Linux/3.13.0-79-generic botocore/1.4.57
EDIT: The following works. Looks like it applies to subdirs of the one specified -- does not include it. This is confusing at best.
|
@1adam thanks! This worked for me for multiple directory excludes. I'm on Win10, so it looks like this: |
Seems like even though the files are at the top level, if you want include/exclude to work, you need the --recursive flag: https://stackoverflow.com/questions/43370710/s3-cli-includes-not-working |
On Windows - when using aws s3 commands (cp or mv) with exclude and/or include parameters the parameters only seem to be honoured if the command is executed from the same drive as the source parameter.
For instance if the source folder is d:\backup and the command is run anywhere from d:\ within cmd then exclude / include parameters are honoured. If the cmd drive is changed to c:\ then the exclude and include parameters appear to be ignored.
See output below
C:>aws s3 cp d:/backups/temp3/ s3://xxx/ --recursive --exclude * --include *.zip
upload: d:\backups\temp3\2.zip to s3://xxx/test/2.zip
upload: d:\backups\temp3\readme.zip to s3://xxx/readme.zip
upload: d:\backups\temp3\readme.txt to s3://xxx/readme.txt (<<< EXTRA FILE PICKED UP)
C:>d:
D:>aws s3 cp d:/backups/temp3/ s3://xxx/ --recursive --exclude * --include *.zip
upload: backups\temp3\readme.zip to s3:/xxx/readme.zip
upload: backups\temp3\2.zip to s3:/xxx/test/2.zip
I've tried various source path syntaxes including d:\backups... d://backups/... but all yield the same result.
The workaround for the time is to ensure cmd is started from the same drive as the source but I assume that isn't by design.
Love the tool in every other way!
The text was updated successfully, but these errors were encountered: