Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-issues@hadoop.apache.org
Message-ID: <1891153721.1252628157484.JavaMail.jira@brutus>
Date: Thu, 10 Sep 2009 17:15:57 -0700 (PDT)
From: "Aaron Kimball (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Subject: [jira] Updated: (MAPREDUCE-971) distcp does not always remove
 distcp.tmp.dir
In-Reply-To: <1635376553.1252627677629.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/MAPREDUCE-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Kimball updated MAPREDUCE-971:
------------------------------------

    Attachment: MAPREDUCE-971.patch

This patch fixes the problem by explcitly creating the temp directory. File open operations in, e.g., hdfs, will auto-create the tmpdir. But in s3n, which expects an object with the name {{_somename_$folder$}}, this won't happen. As a result, the {{fullyDelete()}} call fails (silently) because the folder doesn't exist, even though there are objects with the tmpdir prefix in their object names.

I tested this patch manually by verifying temp dir creation during a distcp to s3n, and verifying that the temp dir object was removed at the end of the transfer.

> distcp does not always remove distcp.tmp.dir
> --------------------------------------------
>
>                 Key: MAPREDUCE-971
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-971
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: distcp
>            Reporter: Aaron Kimball
>            Assignee: Aaron Kimball
>         Attachments: MAPREDUCE-971.patch
>
>
> Sometimes distcp leaves behind its tmpdir when the target filesystem is s3n.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.