Cyberduck Mountain Duck CLI

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#7756 closed defect (fixed)

ACL not maintained when replacing files

Reported by: elgreg Owned by: dkocher
Priority: normal Milestone: 4.4.4
Component: s3 Version: 4.4.3
Severity: normal Keywords:
Cc: Architecture: Intel
Platform: Mac OS X 10.9

Description

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 (1)

Screen Shot 2014-01-29 at 11.34.44 AM.png (729.6 KB) - added by elgreg 5 years ago.
Screenshot of permissions in transfers preferences

Download all attachments as: .zip

Change History (19)

comment:1 Changed 5 years ago by dkocher

  • Component changed from core to s3
  • Milestone set to 4.4.4
  • Owner set to dkocher

comment:2 Changed 5 years ago by dkocher

  • Status changed from new to assigned
  • Summary changed from Permissions not maintained when copying files to s3 to Permissions not maintained when copying files

comment:3 Changed 5 years ago by dkocher

  • Resolution set to fixed
  • Status changed from assigned to closed

In r14254.

comment:4 Changed 5 years ago by elgreg

Thanks!

comment:5 Changed 5 years ago by dkocher

Please update to the latest snapshot build available.

comment:6 Changed 5 years ago by dkocher

  • Summary changed from Permissions not maintained when copying files to ACL not maintained when replacing files

comment:7 Changed 5 years ago by elgreg

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

comment:8 Changed 5 years ago by dkocher

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:9 Changed 5 years ago by dkocher

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

comment:10 follow-up: Changed 5 years ago by dkocher

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:11 Changed 5 years ago by dkocher

Please update to the latest snapshot build available.

comment:12 Changed 5 years ago by elgreg

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

Changed 5 years ago by elgreg

Screenshot of permissions in transfers preferences

comment:13 Changed 5 years ago by dkocher

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:14 in reply to: ↑ 10 Changed 5 years ago by dkocher

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to dkocher:

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

Addendum in r14277.

comment:15 follow-up: Changed 5 years ago by 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

comment:16 Changed 5 years ago by dkocher

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:17 in reply to: ↑ 15 Changed 5 years ago by dkocher

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to 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 #15. Therefore when overwriting a file it defaults to the system default user and group.

comment:18 Changed 5 years ago by Beltran

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.

Note: See TracTickets for help on using tickets.
swiss made software