[
https://issues.apache.org/jira/browse/HADOOP-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494584
]
Doug Cutting commented on HADOOP-1298:
--------------------------------------
> I don't see why you want to OR things. I don't see any possible use for that
> [...]
The OR use is when constructing a permission to pass to chmod(). The AND use
of the constants is when testing permissions, e.g. (from above)
public boolean isOwnerWritable() { return (permissions & OWNER_WRITABLE) != 0; }
> this seperates the FileStatus from the Permissions
Why separate when we can share? DFSFileInfo should extend FileStatus.
> How? What does it have to do with file status?
FileStatus's javadoc should define the meaning of bits in the integer
representation of file permissions. Chmod() takes an integer file permission,
and should reference FileStatus's definition of that representation, no?
> I don't think that a change to the clientside representation of permissions
> should cause a change to the DFS representation of permissions.
These are both in the same project. Sharing's okay here. If we someday neeed
to use a different representation inside HDFS then we can do that then. Until
then, we should avoid replicating logic.
> Permissions is a structure internal to the INode. DFSFileInfo objects are
> just a way to return immutable state to the client.
Good point. So we keep Permissions, or turn it into fields of INode. Still, I
don't see why DFSFileInfo shouldn't extend FileStatus.
> We could move the statics to another class that is instantiated on a per name
> node basis. I'd prefer it to reside in FSDirectory as that is a more
> reasonable place to me.
+1
> adding user info to file
> ------------------------
>
> Key: HADOOP-1298
> URL: https://issues.apache.org/jira/browse/HADOOP-1298
> Project: Hadoop
> Issue Type: New Feature
> Components: dfs, fs
> Reporter: Kurtis Heimerl
> Attachments: hadoop-user-munncha.patch, hadoop-user-munncha.patch,
> hadoop-user-munncha.patch, hadoop-user-munncha.patch10,
> hadoop-user-munncha.patch11, hadoop-user-munncha.patch12,
> hadoop-user-munncha.patch4, hadoop-user-munncha.patch5,
> hadoop-user-munncha.patch6, hadoop-user-munncha.patch7,
> hadoop-user-munncha.patch8, hadoop-user-munncha.patch9
>
>
> I'm working on adding a permissions model to hadoop's DFS. The first step is
> this change, which associates user info with files. Following this I'll
> assoicate permissions info, then block methods based on that user info, then
> authorization of the user info.
> So, right now i've implemented adding user info to files. I'm looking for
> feedback before I clean this up and make it offical.
> I wasn't sure what release, i'm working off trunk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
