Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 9D396200CE0 for ; Fri, 11 Aug 2017 04:35:04 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 9C1AD16CACD; Fri, 11 Aug 2017 02:35:04 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id E2C6F16CACC for ; Fri, 11 Aug 2017 04:35:03 +0200 (CEST) Received: (qmail 99068 invoked by uid 500); 11 Aug 2017 02:35:03 -0000 Mailing-List: contact issues-help@nifi.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@nifi.apache.org Delivered-To: mailing list issues@nifi.apache.org Received: (qmail 99059 invoked by uid 99); 11 Aug 2017 02:35:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Aug 2017 02:35:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 8469C1A037C for ; Fri, 11 Aug 2017 02:35:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id TouheLmzUXHS for ; Fri, 11 Aug 2017 02:35:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 889E45F570 for ; Fri, 11 Aug 2017 02:35:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 1D086E0051 for ; Fri, 11 Aug 2017 02:35:01 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id B948423E7B for ; Fri, 11 Aug 2017 02:35:00 +0000 (UTC) Date: Fri, 11 Aug 2017 02:35:00 +0000 (UTC) From: "Joseph Witt (JIRA)" To: issues@nifi.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (NIFI-4177) MergeContent - Tar - Save modification timestamp like Tar does MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 11 Aug 2017 02:35:04 -0000 [ https://issues.apache.org/jira/browse/NIFI-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122717#comment-16122717 ] Joseph Witt commented on NIFI-4177: ----------------------------------- +1 will merge to master. Follow on work is likely necessary to make it more user friendly. I setup a flow with list/fetch file to merge content. I had file.lastModifiedTime set and also cleared out to see behavior. Always it used the current time of the system rather than the file which suggests the format from ListFile by default wasn't sufficient for the tar needs. We should not have to alter ListFile to use those timestamps of course but rather we should make it easier to specify the timestamp in the merge processor. However, that can come later. As is it builds/tests/and seems to do what the author intended. > MergeContent - Tar - Save modification timestamp like Tar does > -------------------------------------------------------------- > > Key: NIFI-4177 > URL: https://issues.apache.org/jira/browse/NIFI-4177 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions > Affects Versions: 1.3.0 > Reporter: Wayne Steel > Assignee: Joseph Witt > Priority: Trivial > Fix For: 1.4.0 > > > Tar by default saves the modification timestamp of entries. > This mainly affects file based entries so could be done on reading the attribute file.lastModifiedTime, if it exists, which is written to the flowfile by GetFile or ListFile processors. > Otherwise just leave it out as it does now. > I propose a property with the default expression ${file.lastModifiedTime} but the value must resolve to a date format of "yyyy-MM-dd'T'HH:mm:ssZ". It should only be enabled when MERGE_FORMAT is set to MERGE_FORMAT_TAR -- This message was sent by Atlassian JIRA (v6.4.14#64029)