Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permissions > Apply Changes Recursively not working #9657

Closed
cyberduck opened this issue Aug 17, 2016 · 8 comments
Closed

Permissions > Apply Changes Recursively not working #9657

cyberduck opened this issue Aug 17, 2016 · 8 comments
Assignees
Milestone

Comments

@cyberduck
Copy link
Collaborator

cyberduck commented Aug 17, 2016

c19c5a5 created the issue

Execute permissions are not set on non-folders.


Attachments

@cyberduck
Copy link
Collaborator Author

cyberduck commented Aug 19, 2016

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

cyberduck commented Aug 21, 2016

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.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Aug 22, 2016

@dkocher commented

1-Before.png​
2-Apply-Changes-Recursively.png
3-After.png

@cyberduck
Copy link
Collaborator Author

cyberduck commented Aug 22, 2016

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

cyberduck commented Aug 22, 2016

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

@cyberduck
Copy link
Collaborator Author

cyberduck commented Aug 22, 2016

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

@cyberduck
Copy link
Collaborator Author

cyberduck commented Aug 22, 2016

c19c5a5 commented

Thanks :-)

@cyberduck
Copy link
Collaborator Author

cyberduck commented Aug 23, 2016

@dkocher commented

In b27802c and b27802c.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants