Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 81580 invoked from network); 22 Mar 2009 16:48:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 22 Mar 2009 16:48:12 -0000 Received: (qmail 50409 invoked by uid 500); 22 Mar 2009 16:48:11 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 50348 invoked by uid 500); 22 Mar 2009 16:48:11 -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 50338 invoked by uid 99); 22 Mar 2009 16:48:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 22 Mar 2009 16:48:11 +0000 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; Sun, 22 Mar 2009 16:48:11 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C62D1234C004 for ; Sun, 22 Mar 2009 09:47:50 -0700 (PDT) Message-ID: <1381222840.1237740470810.JavaMail.jira@brutus> Date: Sun, 22 Mar 2009 09:47:50 -0700 (PDT) From: "Brian Bockelman (JIRA)" To: core-dev@hadoop.apache.org Subject: [jira] Created: (HADOOP-5551) Namenode permits directory destruction on overwrite MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org Namenode permits directory destruction on overwrite --------------------------------------------------- Key: HADOOP-5551 URL: https://issues.apache.org/jira/browse/HADOOP-5551 Project: Hadoop Core Issue Type: Bug Affects Versions: 0.19.1 Reporter: Brian Bockelman Priority: Critical The FSNamesystem's startFileInternal allows overwriting of directories. That is, if you have a directory named /foo/bar and you try to write a file named /foo/bar, the file is written and the directory disappears. This is most apparent for folks using libhdfs directly, as overwriting is always turned on. Therefore, if libhdfs applications do not check the existence of a directory first, then they will permit new files to destroy directories. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.