[
https://issues.apache.org/jira/browse/HADOOP-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494578
]
Kurtis Heimerl commented on HADOOP-1298:
----------------------------------------
1-> I don't see why you want to OR things. I don't see any possible use for
that, as this is an object that's going to be returned by the file system. As
far as storing as octal/binary, that's not a terrible way to do it. If I were
to do that, I'd need to start at the head and pass the octal representation
around the whole way through. I like the fact that this seperates the
FileStatus from the Permissions, as one is a DFS implementation detail and one
is a client implementation detail.
2-> ok
3-> ok
4-> ok
5-> How? What does it have to do with file status?
6-> ok
7-> I disagree. As state above, these are two different components of two
different systems. I don't think that a change to the clientside representation
of permissions should cause a change to the DFS representation of permissions.
Although they use a very similar mechanism, the seperation is important.
8-> Permissions is a structure internal to the INode. DFSFileInfo objects are
just a way to return immutable state to the client. DFSFileInfo will replicate
some state as it's sent over the wire. For instance, it currently contains
blockReplication taken from the INode. Permissions are just another spot of
state from the inode, so we cannot combine these in any meaningful way. They
perform seperate functions.
Again, FileStatus is an object in the client while DFSFileInfo is an object in
DFS. I like this a lot more than permissions and file status sharing code, as
perhaps filestatus could be a template for the various file system
implementations to return status updates. However, this requires more debate in
my head. FileStatus would need to be more general, as it will be the superclass
of all possible file system permissions returns.
9-> 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.
> 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.
