You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Ferenc Gerlits (Jira)" <ji...@apache.org> on 2021/06/02 13:29:00 UTC

[jira] [Resolved] (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 ]

Ferenc Gerlits resolved MINIFICPP-987.
--------------------------------------
    Resolution: Fixed

> 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: Ferenc Gerlits
>            Priority: Major
>             Fix For: 0.11.0
>
>          Time Spent: 3h
>  Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)