#6491 closed defect (wontfix)
Multipart uploads do not retain ACL
Reported by: | jabeler | Owned by: | dkocher |
---|---|---|---|
Priority: | low | Milestone: | 4.4 |
Component: | s3 | Version: | 4.2.1 |
Severity: | normal | Keywords: | |
Cc: | Architecture: | Intel | |
Platform: | Mac OS X 10.7 |
Description
When uploading certain file types (.zip, .deb, and possibly others) to S3, the permissions are set incorrectly.
For example, overwriting a specific file on S3 previously resulted the bucket/file permissions being carried over to the newly uploaded files. E.G.
Owner = read/write
Everyone = read
Now when uploading zip and deb files only the Owner permission is set, there is no entry for Everyone.
Uploading other files such as .plist, and .txt files result in the correct permissions for both Owner and Everyone.
Change History (6)
comment:1 Changed on Jan 25, 2012 at 12:26:15 AM by Chrispark7
comment:2 Changed on Oct 16, 2012 at 5:29:46 PM by dkocher
- Milestone set to 4.2.2
- Status changed from new to assigned
comment:3 Changed on Nov 24, 2012 at 11:12:28 PM by dkocher
- Milestone changed from 4.2.2 to 4.3
- Summary changed from Upload permissions incorrect for some files to Multipart uploads do not retain ACL
This is less of an issue with the current snapshot build (and upcoming 4.2.2) as we have a much larger threshold for multipart uploads of 5GB.
comment:4 Changed on Nov 25, 2012 at 10:16:41 AM by dkocher
Instead of switching to the snapshot build, you could also change the threshold preference for multipart uploads with
defaults write ch.sudo.cyberduck s3.upload.multipart.threshold 5368709120
comment:5 Changed on Nov 26, 2012 at 6:39:09 PM by dkocher
- Priority changed from normal to low
comment:6 Changed on Jul 23, 2013 at 2:51:50 PM by dkocher
- Milestone changed from 4.5 to 4.4
- Resolution set to wontfix
- Status changed from assigned to closed
The latest snapshot builds do no longer retain existing ACLs.
I can confirm this defect is also new in the windows version of the program, as well. However, it's not based on file type so far as I can tell -- it's based on file size. I'm not sure what the cutoff is, but if the file is smaller than a couple of megabytes then it will keep the permissions of the bucket (or the file that is being overwritten in that case). If the file is about 5mb or larger (for sure -- it may be an issue below that), then 100% of the time it will act as the reporter describes above.
This basically means that, for me, cyberduck is halfway uselses for Amazon S3, because I wind up having to log into the amazon console and set permissions after every upload above a certain size. This was not an issue in 4.1, but I missed a few versions and so I don't know exactly what new version this appeared in.