You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Arpad Boda (JIRA)" <ji...@apache.org> on 2019/07/24 14:34:00 UTC

[jira] [Updated] (MINIFICPP-987) Error handling in GetFile has multiple issues

     [ https://issues.apache.org/jira/browse/MINIFICPP-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arpad Boda updated MINIFICPP-987:
---------------------------------
    Summary: Error handling in GetFile has multiple issues  (was: Error handling in GetFile has multiple isues)

> Error handling in GetFile has multiple issues
> ---------------------------------------------
>
>                 Key: MINIFICPP-987
>                 URL: https://issues.apache.org/jira/browse/MINIFICPP-987
>             Project: Apache NiFi MiNiFi C++
>          Issue Type: Bug
>    Affects Versions: 0.6.0
>            Reporter: Arpad Boda
>            Assignee: Arpad Boda
>            Priority: Major
>
> In case GetFile is set to delete the transferred files, the following check is made:
> {code:java}
> access(fullName.c_str(), W_OK) != 0{code}
> This doesn't really help as the containing folder should be checked on Unix file systems. Not to mention ACL... On Windows, there is no reliable way to predict the result of the delete operation.
> In session::import, we try to delete the file, but the return value of the function is ignored:
> {code:java}
> if (!keepSource)
>   std::remove(source.c_str());{code}
> Which means that in case of failure at delete, the file is going to be transmitted endlessly in every ontrigger call.
> Although adding error handling here (throwing an exception) wouldn't really help as exceptions are handled per execution, not per file. Which means any error (a file couldn't be read for eg.) in the given directory would prevent the processor to transmit the rest. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)