You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@nifi.apache.org by "David Handermann (Jira)" <ji...@apache.org> on 2024/07/12 20:17:00 UTC

[jira] [Updated] (NIFI-13159) Move Remote Delete after Put for PutSFTP REPLACE Conflict Resolution strategy

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

David Handermann updated NIFI-13159:
------------------------------------
    Summary: Move Remote Delete after Put for PutSFTP REPLACE Conflict Resolution strategy  (was: Change how PutSFTP handles the REPLACE Conflict Resolution strategy)

> Move Remote Delete after Put for PutSFTP REPLACE Conflict Resolution strategy
> -----------------------------------------------------------------------------
>
>                 Key: NIFI-13159
>                 URL: https://issues.apache.org/jira/browse/NIFI-13159
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Extensions
>            Reporter: Michael W Moser
>            Assignee: Michael W Moser
>            Priority: Minor
>          Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> In the PutSFTP processor, in the specific case when "Dot Rename = true" and "Conflict Resolution = replace", PutSFTP currently behaves like this:
>  * if remote filename.txt exists, delete it
>  * send file to remote as .filename.txt
>  * rename .filename.txt to filename.txt
> This causes filename.txt to not exist on the remote machine while the SFTP transfer is taking place.  This is different than the PutFile processor, which will wait to replace the file until it has written the "dot file".  Is it possible for PutSFTP to behave like this:
>  * send file to remote as .filename.txt
>  * if remote filename.txt exists, delete it
>  * rename .filename.txt to filename.txt
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)