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 21708200C8B for ; Mon, 22 May 2017 16:49:10 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 1FF4B160BBF; Mon, 22 May 2017 14:49:10 +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 66942160BA5 for ; Mon, 22 May 2017 16:49:09 +0200 (CEST) Received: (qmail 81038 invoked by uid 500); 22 May 2017 14:49:07 -0000 Mailing-List: contact issues-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list issues@camel.apache.org Received: (qmail 81029 invoked by uid 99); 22 May 2017 14:49:07 -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; Mon, 22 May 2017 14:49:07 +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 34B2F1A092E for ; Mon, 22 May 2017 14:49:07 +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 Y2MoUgH_00lY for ; Mon, 22 May 2017 14:49:06 +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 D555B5FDF0 for ; Mon, 22 May 2017 14:49:04 +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 55B74E0012 for ; Mon, 22 May 2017 14:49:04 +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 1481E21B57 for ; Mon, 22 May 2017 14:49:04 +0000 (UTC) Date: Mon, 22 May 2017 14:49:04 +0000 (UTC) From: "ASF GitHub Bot (JIRA)" To: issues@camel.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CAMEL-11298) Using chmodDirectory with full paths makes file producer to created directories relative to source MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 22 May 2017 14:49:10 -0000 [ https://issues.apache.org/jira/browse/CAMEL-11298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019652#comment-16019652 ] ASF GitHub Bot commented on CAMEL-11298: ---------------------------------------- GitHub user Stabbz opened a pull request: https://github.com/apache/camel/pull/1707 CAMEL-11298: Fix, allowing usage of absolute and relative paths with chmodDirectory option Reused the absolute boolean flag to handle absolute paths when using chmodDirectory option. Previously using absolute paths produced an exception. You can merge this pull request into a Git repository by running: $ git pull https://github.com/Stabbz/camel chmod-dir-fix Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/1707.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1707 ---- commit 995ff7e1640fe285eb66c948d8f487c918991c26 Author: Damyan Damyanov Date: 2017-05-22T11:41:34Z CAMEL-11298: Minor change to file constructor used in chmodDirectory. Should fix the issue. commit b91e1d21e3e0b50e95e12b793610c956ce1e7950 Author: Damyan Damyanov Date: 2017-05-22T14:43:49Z CAMEL-11298: Added additional logic to handle absolute and relative paths when using chmodDirectory. ---- > Using chmodDirectory with full paths makes file producer to created directories relative to source > -------------------------------------------------------------------------------------------------- > > Key: CAMEL-11298 > URL: https://issues.apache.org/jira/browse/CAMEL-11298 > Project: Camel > Issue Type: Bug > Components: camel-core > Affects Versions: 2.18.2, 2.19.0 > Environment: Arch Linux > Reporter: Damyan Damyanov > Fix For: 2.18.5, 2.19.1, 2.20.0 > > > Tried using the chmodDirectory property on a file producer that writes to full system paths and noticed that with the chmodDirectory property the directories get created relative to the source/project. > Without using the property the files get properly created using the full path that is given to them. > I ran a debugger and found the source of the problem: > Code is from org.apache.camel.component.file.FileOperations > in buildDirectory method > at lines 97 - 118 > {code} > if (permissions == null || permissions.isEmpty()) { > return dir.mkdirs(); > } > // create directory one part of a time and set permissions > try { > String[] parts = dir.getPath().split("\\" + File.separatorChar); > File base = new File("."); > for (String part : parts) { > File subDir = new File(base, part); > if (!subDir.exists()) { > if (subDir.mkdir()) { > if (LOG.isTraceEnabled()) { > LOG.trace("Setting chmod: {} on directory: {} ", PosixFilePermissions.toString(permissions), subDir); > } > Files.setPosixFilePermissions(subDir.toPath(), permissions); > } else { > return false; > } > } > base = new File(base, subDir.getName()); > } > } > {code} > Base File used to create all the folders and set their permissions is initialized with new File("."), effectively this always creates the directories given to it, relative to the source, and will not handle full system paths. > Is there a reason I'm unaware of that this is implemented this way? > I tested running folder creation code with new File("") as a base and it worked fine, would that be enough to handle the issue if it indeed is an issue? > I can do this my self by issuing a pull request, let me know. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.15#6346)