[
https://issues.apache.org/jira/browse/HDFS-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349283#comment-14349283
]
Colin Patrick McCabe commented on HDFS-7838:
--------------------------------------------
Thanks for looking at this, Yi.
{code}
1080 errno = ret;
{code}
We shouldn't set {{errno}} on success, only on failure.
Also, it seems like we can accidentally return success (1) here even on failure
if this returns 1:
{code}
1067 if (jthr) {
1068 ret = printExceptionAndFree(env, jthr, PRINT_EXC_ALL,
1069 "hdfsTruncateFile(%s): FileSystem#truncate", path);
1070 goto done;
1071 }
{code}
Keep in mind that 1 is a valid errno code. On Linux:
{code}
#ifndef _ASM_GENERIC_ERRNO_BASE_H
#define _ASM_GENERIC_ERRNO_BASE_H
#define EPERM 1 /* Operation not permitted */
#define ENOENT 2 /* No such file or directory */
#define ESRCH 3 /* No such process */
...
{code}
This also violates the comment in the header file that the function returns -1
on failure. It seems that the function actually returns a positive number on
failure, currently.
{code}
78 typedef int64_t tNewLength;/// new length to be truncated to
{code}
We don't need another type for this... just use {{tOffset}}. Or better yet,
just use {{int64_t}}, since that's what it is always going to be.
Also, can you add a stub {{hdfsTruncateFile}} function to libwebhdfs that
returns ENOTSUP, and file a jira to add truncate support to libwebhdfs? or
just implement it in this patch, your choice.
> Expose truncate API for libhdfs
> -------------------------------
>
> Key: HDFS-7838
> URL: https://issues.apache.org/jira/browse/HDFS-7838
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: datanode, namenode
> Affects Versions: 2.7.0
> Reporter: Yi Liu
> Assignee: Yi Liu
> Fix For: 2.7.0
>
> Attachments: HDFS-7838.001.patch
>
>
> It's good to expose truncate in libhdfs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)