Cyberduck Mountain Duck CLI

#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 on Jan 29, 2014 at 4:38:17 PM.
Screenshot of permissions in transfers preferences

Download all attachments as: .zip

Change History (19)

comment:1 Changed on Jan 23, 2014 at 4:44:52 PM by dkocher

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

comment:2 Changed on Jan 24, 2014 at 10:29:32 AM 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 on Jan 28, 2014 at 9:59:09 PM by dkocher

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

In r14254.

comment:4 Changed on Jan 29, 2014 at 12:54:09 AM by elgreg

Thanks!

comment:5 Changed on Jan 29, 2014 at 9:56:38 AM by dkocher

Please update to the latest snapshot build available.

comment:6 Changed on Jan 29, 2014 at 11:41:08 AM by dkocher

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

comment:7 Changed on Jan 29, 2014 at 2:31:23 PM 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 on Jan 29, 2014 at 2:39:24 PM by dkocher

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:9 Changed on Jan 29, 2014 at 3:17:22 PM by dkocher

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

comment:10 follow-up: Changed on Jan 29, 2014 at 3:23:02 PM 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 on Jan 29, 2014 at 3:38:17 PM by dkocher

Please update to the latest snapshot build available.

comment:12 Changed on Jan 29, 2014 at 4:37:50 PM 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 on Jan 29, 2014 at 4:38:17 PM by elgreg

Screenshot of permissions in transfers preferences

comment:13 Changed on Jan 29, 2014 at 6:20:22 PM by dkocher

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:14 in reply to: ↑ 10 Changed on Jan 29, 2014 at 8:39:03 PM 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 on Feb 3, 2014 at 3:23:15 PM 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 on Feb 3, 2014 at 8:40:08 PM by dkocher

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:17 in reply to: ↑ 15 Changed on Feb 3, 2014 at 8:42:33 PM 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 on Feb 4, 2014 at 7:53:13 AM 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