@dkocher commented

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

c19c5a5 commented

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.

@dkocher commented

@dkocher commented

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

c19c5a5 commented

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

@dkocher commented

Replying to [comment:6 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.

c19c5a5 commented

Thanks :-)

@dkocher commented

In b27802c and b27802c.