ACL not maintained when replacing files

[cyberduck]

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

• Screen Shot 2014-01-29 at 11.34.44 AM.png (729.6 KiB)

[cyberduck]

@dkocher commented

In 2fdf76e.

[cyberduck]

fdb2e60 commented

Thanks!

[cyberduck]

@dkocher commented

Please update to the latest snapshot build available.

[cyberduck]

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]

@dkocher commented

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

[cyberduck]

@dkocher commented

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

[cyberduck]

@dkocher commented

Please update to the latest snapshot build available.

[cyberduck]

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]

@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]

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]

@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]

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.