Return-Path: X-Original-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 665421021A for ; Thu, 18 Apr 2013 07:42:53 +0000 (UTC) Received: (qmail 86239 invoked by uid 500); 18 Apr 2013 07:42:48 -0000 Delivered-To: apmail-hadoop-hdfs-user-archive@hadoop.apache.org Received: (qmail 86120 invoked by uid 500); 18 Apr 2013 07:42:47 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 86102 invoked by uid 99); 18 Apr 2013 07:42:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Apr 2013 07:42:47 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [173.205.127.22] (HELO ehub22.webhostinghub.com) (173.205.127.22) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Apr 2013 07:42:42 +0000 Received: from mail-lb0-f176.google.com ([209.85.217.176]:39447) by ehub22.webhostinghub.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1USjU5-0007bf-LT for user@hadoop.apache.org; Thu, 18 Apr 2013 03:42:21 -0400 Received: by mail-lb0-f176.google.com with SMTP id y8so2368906lbh.7 for ; Thu, 18 Apr 2013 00:42:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:reply-to:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ea6std+6NBkLQxCPfOrP8jO7HpkX4olDyI5jcR6YRkk=; b=HoVW45q3GoUlXEDdOMvryD43rI8kfY672s0wdlL34AEP5dgnLe/wQCyvSEI4oMDyXu TdFoZ3w32ECXmWnWyOmLBPK2YyJJV/yo2gTEALyB5OnGXWDNFh5BHN5VT+2kiu7wOs3L pkKQ7bB48IB/TkHUYxw0RTNUIfcwHR4oDqBnRKjrozgay4/SUVguXQ0Iwqg4xW0yXEKE 5ruJFe3GdRLOR60ClugWWFYhq7mkLgz2wCHv8lj9a4zTKhCVuLDS10SzQbKUomRUSJ2c RvrbKzmBaWdnktB6BroRTRg0kYL5qfv90IXnFvXt5x6iLfwhpfrcpTAVG7Prvda0MRSb Yu9g== X-Received: by 10.112.141.71 with SMTP id rm7mr4782890lbb.7.1366270940330; Thu, 18 Apr 2013 00:42:20 -0700 (PDT) MIME-Version: 1.0 Reply-To: fabio.pitzolu@gr-ci.com Received: by 10.112.76.164 with HTTP; Thu, 18 Apr 2013 00:41:50 -0700 (PDT) In-Reply-To: References: From: Fabio Pitzolu Date: Thu, 18 Apr 2013 09:41:50 +0200 Message-ID: Subject: Re: Hadoop fs -getmerge To: Hemanth Yamijala Cc: "user@hadoop.apache.org" Content-Type: multipart/alternative; boundary=001a11c33b1c10ca2504da9dbe48 X-OutGoing-Spam-Status: No, score=-2.8 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ehub22.webhostinghub.com X-AntiAbuse: Original Domain - hadoop.apache.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gr-ci.com X-Get-Message-Sender-Via: ehub22.webhostinghub.com: authenticated_id: fabio.pitzolu+gr-ci.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: X-Virus-Checked: Checked by ClamAV on apache.org --001a11c33b1c10ca2504da9dbe48 Content-Type: text/plain; charset=ISO-8859-1 Hi Hemanth, I guess that the only solution is to delete the crc files after the export. Does anyone of you knows if someone filed a Jira to implement a parameter to -getmerge to delete the crc files afterwards? *Fabio Pitzolu* Consultant - BI & Infrastructure Mob. +39 3356033776 Telefono 02 87157239 Fax. 02 93664786 *Gruppo Consulenza Innovazione - http://www.gr-ci.com* 2013/4/18 Hemanth Yamijala > I don't think that is possible. When we use -getmerge, the destination > filesystem happens to be a LocalFileSystem which extends from > ChecksumFileSystem. I believe that's why the CRC files are getting in. > > Would it not be possible for you to ignore them, since they have a fixed > extension ? > > Thanks > Hemanth > > > On Wed, Apr 17, 2013 at 8:09 PM, Fabio Pitzolu wrote: > >> Hi all, >> is there a way to use the "*getmerge*" fs command and not generate the >> .crc files in the output local directory? >> >> Thanks, >> >> Fabio Pitzolu** >> > > --001a11c33b1c10ca2504da9dbe48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hemanth,
I guess that the only solution is to delete the crc files after the export.=
Does anyone of you knows if someone filed a Jira = to implement a parameter to -getmerge to delete the crc files afterwards?



Fa= bio Pitzolu
Consultant - BI & I= nfrastructure

Mob. +39 3356033776
Telefono 02 87157239
Fax. 02 93664786

Gruppo Consulenza Innovazione - http://www.gr-ci.com


2013/4/18 Hemanth Yamijala <yhe= manth@thoughtworks.com>
I don't think that is possible. When we use -getmerge,= the destination filesystem happens to be a LocalFileSystem which extends f= rom ChecksumFileSystem. I believe that's why the CRC files are getting = in.

Would it not be possible for you to ignore them, since they = have a fixed extension ?

Thanks
Hemanth
<= div class=3D"HOEnZb">


On Wed, Apr 17, 2013 at 8:09 PM, Fabio Pitzolu <fabio.pitzolu@gr-ci.= com> wrote:
Hi all,
is there a way to use the "getmerge" fs command and not ge= nerate the .crc files in the output local directory?

Thanks,

Fabio Pitzolu=


--001a11c33b1c10ca2504da9dbe48--