[ https://issues.apache.org/jira/browse/HADOOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555754#action_12555754 ]
Sanjay Radia commented on HADOOP-2514: -------------------------------------- >> need to handle case where a user, that does not have private trash, issues a >> delete file operation. >Can't we simply create one on demand in this case? If the per-user trash is in a common /trash as in /trash/<userName> then one cannot create the trash-bin on the fly on the client side. A user does not have write permission on /trash; only on /trash/<user>. If trash is in /user/<userName>/.trash, then we can create it on demand, but then the problem occurs when the user deleting the file does not have a home directory. (Because there is single trash compacter, it seems better to have all the per-user trashbins be in /trash.; but this is separable issue.) So we can do the following: if the per-user trash-bin exists then move it there otherwise move it to /trash/common (or merely throw an exception). > Trash and permissions don't mix > ------------------------------- > > Key: HADOOP-2514 > URL: https://issues.apache.org/jira/browse/HADOOP-2514 > Project: Hadoop > Issue Type: New Feature > Components: dfs > Affects Versions: 0.16.0 > Reporter: Robert Chansler > Fix For: 0.16.0 > > > Shell command "rm" is really "mv" to trash with the expectation that the > server will at some point really delete the contents of trash. With the > advent of permissions, a user can "mv" folders that the user cannot "rm". The > present trash feature as implemented would allow the user to suborn the > server into deleting a folder in violation of the permissions model. > A related issue is that if anybody can mv a folder to the trash anybody else > can mv that same folder from the trash. This may be contrary to the > expectations of the user. > What is a better model for trash? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.