Cyberduck Mountain Duck CLI

#9657 closed defect (fixed)

Permissions > Apply Changes Recursively not working

Reported by: charlesrich Owned by: dkocher
Priority: normal Milestone: 5.1
Component: core Version: 5.0.11
Severity: normal Keywords: Permissions
Cc: Architecture: Intel
Platform: Mac OS X 10.10

Description (last modified by charlesrich)

Execute permissions are not set on non-folders.

Attachments (3)

1-Before.png (151.4 KB) - added by charlesrich on Aug 20, 2016 at 11:01:01 PM.
2-Apply-Changes-Recursively.png (151.6 KB) - added by charlesrich on Aug 20, 2016 at 11:01:13 PM.
3-After.png (147.2 KB) - added by charlesrich on Aug 20, 2016 at 11:01:25 PM.

Download all attachments as: .zip

Change History (12)

comment:1 Changed on Aug 19, 2016 at 8:37:07 AM by dkocher

  • Resolution set to worksforme
  • Status changed from new to closed

Please provide the steps to reproduce including a screenshot that shows the issue.

Changed on Aug 20, 2016 at 11:01:01 PM by charlesrich

Changed on Aug 20, 2016 at 11:01:13 PM by charlesrich

Changed on Aug 20, 2016 at 11:01:25 PM by charlesrich

comment:2 Changed on Aug 20, 2016 at 11:04:41 PM by charlesrich

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Respectfully, it does not "work for me". Please see attached simple documentation. Notice in 1-Before.png, the file index.html has execute permissions only for owner. Then in 2-Apply-Changes-Recursively.png, I have checked the execution privileges for Group and Other on the parent folder and then pressed the "Apply changes recursively button". Finally, note in 3-After.png that the new permissions have not been changed on index.html file.

comment:4 Changed on Aug 22, 2016 at 8:16:19 AM by dkocher

  • Milestone set to 5.1
  • Owner set to dkocher
  • Status changed from reopened to new

comment:5 Changed on Aug 22, 2016 at 8:18:29 AM by dkocher

This is due to #1787. Currently we ignore execute permissions when applied recursively for files.

comment:6 follow-up: Changed on Aug 22, 2016 at 12:11:25 PM by charlesrich

  • Description modified (diff)

I see. This is an undocumented and unfortunate behavior. For example (and there may be others), the x-bit is used by web servers, such as Apache, to control the parsing of Server Side Includes (see XBitHack at https://httpd.apache.org/docs/current/howto/ssi.html). So I needed to use "Apply changes recursively" to the x-bit at the root folder of a large web site to make sure all of the includes everywhere in the site were processed.

At MINIMUM, the current behavior should be changed to give a pop-up warning message saying that Apply changes recursively was ignored for the x-bit on a particular invocation. Currently, there is no hint that the changes were not applied everywhere and I wasted a lot of time trying to figure out why SSI wasn't working, until I sample-checked a few permissions.

Personally, I think that Cyberduck simply ought to do what the user asks and apply the changes recursively, regardless of whether it involves setting x-bits on non-folders.

But if there is strong feeling that this is not the right behavior, then a good compromise would be a pop-up window that asks (when appropriate) "Do you want to set execute permission on non-folders?"

Tx, -CR

comment:7 in reply to: ↑ 6 Changed on Aug 22, 2016 at 12:23:51 PM by dkocher

  • Status changed from new to assigned

Replying to charlesrich:

I see. This is an undocumented and unfortunate behavior. For example (and there may be others), the x-bit is used by web servers, such as Apache, to control the parsing of Server Side Includes (see XBitHack at https://httpd.apache.org/docs/current/howto/ssi.html). So I needed to use "Apply changes recursively" to the x-bit at the root folder of a large web site to make sure all of the includes everywhere in the site were processed.

At MINIMUM, the current behavior should be changed to give a pop-up warning message saying that Apply changes recursively was ignored for the x-bit on a particular invocation. Currently, there is no hint that the changes were not applied everywhere and I wasted a lot of time trying to figure out why SSI wasn't working, until I sample-checked a few permissions.

Personally, I think that Cyberduck simply ought to do what the user asks and apply the changes recursively, regardless of whether it involves setting x-bits on non-folders.

But if there is strong feeling that this is not the right behavior, then a good compromise would be a pop-up window that asks (when appropriate) "Do you want to set execute permission on non-folders?"

Tx, -CR

I fully agree with your take on this.

comment:8 Changed on Aug 22, 2016 at 12:35:41 PM by charlesrich

Thanks :-)

comment:9 Changed on Aug 23, 2016 at 7:31:41 PM by dkocher

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

In r21294 and r21296.

Last edited on Aug 24, 2016 at 6:53:19 AM by dkocher (previous) (diff)
Note: See TracTickets for help on using tickets.
swiss made software