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

ACL not maintained when replacing files #7756

Closed
cyberduck opened this issue Jan 23, 2014 · 12 comments
Closed

ACL not maintained when replacing files #7756

cyberduck opened this issue Jan 23, 2014 · 12 comments
Assignees
Labels
bug fixed s3 AWS S3 Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

fdb2e60 created the issue

When I drag and drop files to my s3 bucket overwriting an existing file, the permission of the existing file are not maintained. This worked in previous versions.


Attachments

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In 2fdf76e.

@cyberduck
Copy link
Collaborator Author

fdb2e60 commented

Thanks!

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Please update to the latest snapshot build available.

@cyberduck
Copy link
Collaborator Author

fdb2e60 commented

Just tested with the snapshot and it's still overwriting existing permissions. Steps to repeat:

  1. Go to bucket on S3 in Cyberduck and find a file with multiple permissions
  2. View file meta data (Command+I) -> permissions
  3. See owner set to FULL_CONTROL and Everyeone set to READ
  4. Drag same file to Cyberduck to upload
  5. Confirm overwrite and upload file
  6. Refresh (optional, but tried it)
  7. View file meta data (Command+I) -> permissions

Result:
File permissions have owner set to FULL_CONTROL, but no other permissions listed

Expected result:
File has same permissions as original overwritten file

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Make sure to check "Preferences → Transfers → Permissions → Uploads → Change permissions".

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Additional fix to preserve existing ACL and UNIX permissions regardless of upload preference in a787ee0.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Please update to the latest snapshot build available.

@cyberduck
Copy link
Collaborator Author

fdb2e60 commented

Still happening on the latest snapshot. Attaching my permissions in a screenshot. Ideally uploads would maintain the permission of the remote file they replace.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:10 dkocher]:

Additional fix to preserve existing ACL and UNIX permissions regardless of upload preference in a787ee0.

Addendum in 83285cc.

@cyberduck
Copy link
Collaborator Author

6a2066b commented

It seems this issue was not solved if you try to edit a file directly. I could reproduce it with the latest version (4.4.3) and the latest nightly build.

File permissions: 750 user:daemon

If I edit the file: 750 user:user

If I download and upload the file it works properly: 750 user:daemon

Could be possible that you also have to fix the "core/transfer/copy/CopyTransferFilter.java" file?

Thanks

@cyberduck
Copy link
Collaborator Author

cyberduck commented Feb 3, 2014

@dkocher commented

Replying to [comment:15 Beltran]:

It seems this issue was not solved if you try to edit a file directly. I could reproduce it with the latest version (4.4.3) and the latest nightly build.

File permissions: 750 user:daemon

If I edit the file: 750 user:user

If I download and upload the file it works properly: 750 user:daemon

Could be possible that you also have to fix the "core/transfer/copy/CopyTransferFilter.java" file?

Thanks

We do not support changing the group owner of a file (using FTP or SFTP). See issue #11965. Therefore when overwriting a file it defaults to the system default user and group.

@cyberduck
Copy link
Collaborator Author

6a2066b commented

Thanks. It strange for me that it is supported if I download, edit the file and upload again (the file maintains the correct user and group that have in the remote machine) and not when you edit the file directly. Let me know if I'm missing something.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug fixed s3 AWS S3 Protocol Implementation
Projects
None yet
Development

No branches or pull requests

2 participants