Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 15657 invoked from network); 17 May 2008 00:44:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 May 2008 00:44:17 -0000 Received: (qmail 64756 invoked by uid 500); 17 May 2008 00:44:18 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 64725 invoked by uid 500); 17 May 2008 00:44:18 -0000 Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: core-dev@hadoop.apache.org Delivered-To: mailing list core-dev@hadoop.apache.org Received: (qmail 64714 invoked by uid 99); 17 May 2008 00:44:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 May 2008 17:44:18 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 May 2008 00:43:40 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id E4B67234C116 for ; Fri, 16 May 2008 17:43:55 -0700 (PDT) Message-ID: <192491396.1210985035935.JavaMail.jira@brutus> Date: Fri, 16 May 2008 17:43:55 -0700 (PDT) From: "Tsz Wo (Nicholas), SZE (JIRA)" To: core-dev@hadoop.apache.org Subject: [jira] Commented: (HADOOP-3400) Facilitate creation of temporary files in HDFS In-Reply-To: <323885949.1210900495547.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HADOOP-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597668#action_12597668 ] Tsz Wo (Nicholas), SZE commented on HADOOP-3400: ------------------------------------------------ - Would it better call it deleteOnClose? - FileSystem.delete(path) is deprecated. We should use FileSystem.delete(path, recursive). Should we let the user specify "recursive"? - If processDeleteOnExit() throws an IOException, then the FileSystem won't be closed properly and it will remain in the cache. I think processDeleteOnExit() should not throws exceptions. > Facilitate creation of temporary files in HDFS > ---------------------------------------------- > > Key: HADOOP-3400 > URL: https://issues.apache.org/jira/browse/HADOOP-3400 > Project: Hadoop Core > Issue Type: Improvement > Components: dfs > Reporter: dhruba borthakur > Assignee: dhruba borthakur > Attachments: deleteOnExit.patch > > > There are a set of applications that use HDFS to create temporary files. The application would ideally like these files to be automatically deleted when the application process exits. This is similar to the File.deleteOnExit() in the Java API. > One proposal is to add a new method in FileSystem > public void deleteOnExit(Path) > This API requests that the file or directory denoted by this abstract pathname be deleted when the virtual machine terminates. Deletion will be attempted only for normal termination of the virtual machine, as defined by the Java Language Specification. Once deletion has been requested, it is not possible to cancel the request. This method should therefore be used with care. > This method can be implemented entirely in the client side code, e.g. FileSystem.java will keep a cache of all the pathnames specified by the above API. FileSystem.close will invoke delete() on all the pathnames found in the cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.