[
https://issues.apache.org/jira/browse/HDFS-6516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051926#comment-14051926
]
Colin Patrick McCabe commented on HDFS-6516:
--------------------------------------------
{code}
assert hasWriteLock();
// Verify that the destination does not exist as a directory already.
final INodesInPath iip = dir.getINodesInPath4Write(src);
final INode inode = iip.getLastINode();
if (inode != null && inode.isDirectory()) {
throw new FileAlreadyExistsException(src +
" already exists as a directory");
}
FileEncryptionInfo feInfo = null;
CipherSuite suite = chooseCipherSuite(src, cipherSuites);
if (suite != null) {
{code}
You already computed the {{INodesInPath}} here, so why not simply pass that
into {{chooseCipherSuite}}, rather than recomputing it in {{isInAnEZ}}? We're
not dropping the lock in between.
{code}
private EncryptionZoneInt getEncryptionZoneForPath(INodesInPath iip) {
Preconditions.checkNotNull(iip);
final INode[] inodes = iip.getINodes();
for (int i = 0; i < inodes.length; i++) {
final INode inode = inodes[i];
if (inode != null) {
final EncryptionZoneInt ezi = encryptionZones.get(inode.getId());
if (ezi != null) {
return ezi;
}
}
}
return null;
}
{code}
It seems like this 'for' loop should be going the other way around. As it is,
an EZ further up the filesystem tree will hide one further down, which seems
backwards. In other words, if I have an EZ located in /a and one located in
/a/b, the second one should be used for /a/b/c.
> List of Encryption Zones should be based on inodes
> --------------------------------------------------
>
> Key: HDFS-6516
> URL: https://issues.apache.org/jira/browse/HDFS-6516
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: security
> Reporter: Charles Lamb
> Assignee: Charles Lamb
> Attachments: HDFS-6516.001.patch, HDFS-6516.002.patch,
> HDFS-6516.003.patch
>
>
> The list Encryption Zones command (CLI) and backend implementation
> (FSNamesystem) needs to be implemented. As part of this, the tests in
> TestEncryptionZonesAPI should be updated to use that to validate the results
> of the various CreateEZ and DeleteEZ tests.
--
This message was sent by Atlassian JIRA
(v6.2#6252)