Description
What is the problem?
Gvidas Razevicius noticed that when using the CompressUpload API with a prefix that was deeply nested that the zip file preserves this deep nesting. For example, given the following structure in S3
+ foo
|
+ bar
|
+ baz
|
+ 01.txt
|
and asking to CompressUpload foo/bar we will have a zip file containing a single file 01.txt, but with the file hierarchy maintained, i.e. the file is located at foo/bar/baz. We would expect that it would maintain the hierarchy only up to the path prefix, i.e. baz/01.txt.
What is the fix?
When writing the file to the zip we should strip the original prefix off the key. This will give us the correct structure in the zip file.