{"action":"created","issue":{"url":"https://api.github.com/repos/arpitkh96/AmazeFileManager/issues/473","repository_url":"https://api.github.com/repos/arpitkh96/AmazeFileManager","labels_url":"https://api.github.com/repos/arpitkh96/AmazeFileManager/issues/473/labels{/name}","comments_url":"https://api.github.com/repos/arpitkh96/AmazeFileManager/issues/473/comments","events_url":"https://api.github.com/repos/arpitkh96/AmazeFileManager/issues/473/events","html_url":"https://github.com/arpitkh96/AmazeFileManager/issues/473","id":212273547,"number":473,"title":"Unable to Modify Permissions (Interface Missing)","user":{"login":"GuardianMajor","id":5274181,"avatar_url":"https://avatars1.githubusercontent.com/u/5274181?v=3","gravatar_id":"","url":"https://api.github.com/users/GuardianMajor","html_url":"https://github.com/GuardianMajor","followers_url":"https://api.github.com/users/GuardianMajor/followers","following_url":"https://api.github.com/users/GuardianMajor/following{/other_user}","gists_url":"https://api.github.com/users/GuardianMajor/gists{/gist_id}","starred_url":"https://api.github.com/users/GuardianMajor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GuardianMajor/subscriptions","organizations_url":"https://api.github.com/users/GuardianMajor/orgs","repos_url":"https://api.github.com/users/GuardianMajor/repos","events_url":"https://api.github.com/users/GuardianMajor/events{/privacy}","received_events_url":"https://api.github.com/users/GuardianMajor/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2017-03-06T22:43:05Z","updated_at":"2017-03-09T05:25:08Z","closed_at":"2017-03-07T02:26:13Z","body":"First off, let me say I like the look and feel and looking forward to it being a real competitor to Root Explorer (UX is atrocious) and ES Explorer (bloated approaching malware status) they just destroyed it with crap - any company installing their own SU whether you are rooted or not and bypassing your system is not my idea of legitimate or trustworthy. So take what I am about to say in the spirit of caring and genuine inquiry, not complaining.\r\n\r\nIs this seriously missing the ability to manage permissions or am I missing something? Seeing permissions is not as helpful as actually being able to do something with them. This ability is one of the most basic and core functionality of any File Explorer, especially if they are providing \"root\" option. This should have literally been one of the first 5 things to put in a file manager.\r\n\r\nI mean what exactly is the app doing with root permissions that it can't provide the basic permission change? Using root access just for basic rwx functions seems a great and utter waste of that option. It would be the equivalent to having a super computer to check email or read news :)\r\n\r\nI really want to like this app, the interface is glitchy but clean enough, I like it - even if the focus is on looks rather than function. The functionality is the part that is lacking, beyond the basic view/copy/move/create, I mean any app does that, even the built-in browser on Android does that (not well but again, why did IE win so long? it was there and worked). So to have this overhead installed, you have to get some extra benefits from it, so far doing a decent job (like the SMB, which only a small comparative portion of the users need - I use, so thank you - or the FTP - even I don't find use for that) but the lack of this ability (which 99% using a file manager on rooted Android do in contrast) makes ZERO sense in a world where managers are becoming just me toos :/\r\n\r\nAny thoughts on this? preferably from people who actually work with the code like the developer(s), not spectators guessing or making assumptions. Thank you in advance and keep up the good work, hoping for meaningful productive discussion, so don't just add noise.\r\n\r\nSome thoughts looking at this : [File object](https://developer.android.com/reference/java/io/File.html), we already have some set* methods that will handle quick permissions without resorting to FileUtils reflection for the time being. Specifically: [setReadable](https://developer.android.com/reference/java/io/File.html#setReadable(boolean,%20boolean)), [setWritable](https://developer.android.com/reference/java/io/File.html#setWritable(boolean,%20boolean)), and [setExecutable](https://developer.android.com/reference/java/io/File.html#setExecutable(boolean,%20boolean)). This would be a stopgap measure to provide the functionality while a more robust system is put in place to handle more than just basic setting to include other ownership flags too down the line. It also adds little to no overhead since the File object is already a core reference being used (from the quick look at the code).\r\n\r\nTake care."},"comment":{"url":"https://api.github.com/repos/arpitkh96/AmazeFileManager/issues/comments/285257937","html_url":"https://github.com/arpitkh96/AmazeFileManager/issues/473#issuecomment-285257937","issue_url":"https://api.github.com/repos/arpitkh96/AmazeFileManager/issues/473","id":285257937,"user":{"login":"GuardianMajor","id":5274181,"avatar_url":"https://avatars1.githubusercontent.com/u/5274181?v=3","gravatar_id":"","url":"https://api.github.com/users/GuardianMajor","html_url":"https://github.com/GuardianMajor","followers_url":"https://api.github.com/users/GuardianMajor/followers","following_url":"https://api.github.com/users/GuardianMajor/following{/other_user}","gists_url":"https://api.github.com/users/GuardianMajor/gists{/gist_id}","starred_url":"https://api.github.com/users/GuardianMajor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GuardianMajor/subscriptions","organizations_url":"https://api.github.com/users/GuardianMajor/orgs","repos_url":"https://api.github.com/users/GuardianMajor/repos","events_url":"https://api.github.com/users/GuardianMajor/events{/privacy}","received_events_url":"https://api.github.com/users/GuardianMajor/received_events","type":"User","site_admin":false},"created_at":"2017-03-09T05:25:08Z","updated_at":"2017-03-09T05:25:08Z","body":"Ok, just thinking out loud here, can't we change this code to something like this:\r\n\r\n```\r\nif(root) {\r\n    try{\r\n        appCompatButton.setVisibility(View.VISIBLE);\r\n        appCompatButton.setOnClickListener(new View.OnClickListener() {\r\n                @Override\r\n                public void onClick(View v) {\r\n                    if (permtabl.getVisibility() == View.GONE) {\r\n                        permtabl.setVisibility(View.VISIBLE);\r\n                        but.setVisibility(View.VISIBLE);\r\n                        setPermissionsDialog(permtabl, but, hFile, perm, c);\r\n                    } else {\r\n                        but.setVisibility(View.GONE);\r\n                        permtabl.setVisibility(View.GONE);\r\n                    }\r\n                }\r\n            });\r\n        }catch(e){\r\n            // means perm.length()<6\r\n            // we add a graceful handler\r\n            // to do what you are doing now\r\n            // with the character limitation\r\n            // this way you are behaving more\r\n            // like a firewall rule ...\r\n            // allow what you allow and catch the rest\r\n        }\r\n}\r\n```\r\nRight now you are neutering it by casting a really wide net and that's not necessary - IMHO; this way you allow the routine to try and show the interface and continue with the function.\r\n\r\nIf it encounters an error then you know you hit that <6 condition (which I still don't understand why it matters to you), then do at that point what you do NOW and gracefully continue.\r\n\r\nIt may not look like the prettiest thing but the fact is that it will be far more efficient, like sometimes needing a catch all so you can hit a few condition and let the rest drop.\r\n\r\nFor performance sake - because sometimes processing power is cheaper than the memory cost of carrying extra baggage - so this way you shift the balancing toward the CPU which is negligible here. \r\n\r\nIn my humble opinion, letting a try/catch block handle the valid parts and bypass the exception is a much more stable implementation, even if a bit \"hacky\".\r\n\r\nThoughts? I'd happily be a guinea pig and test it out to work through the logic if you can build it for me, as I am not setup with a compile environment where I am, to do it myself. \r\n\r\nHave a good night everyone and as promised here is a screenshot for you.\r\n\r\n![screenshot_20170308-201625](https://cloud.githubusercontent.com/assets/5274181/23736986/dae6d654-0444-11e7-8fcc-c3ff5f27dc47.png)\r\n*\\*clearly the permissions are less than 6 characters but it should not matter\\**"}}
{"actor":{"display_login":"GuardianMajor"}}