You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That is: consider the file located under remote-directory-expression, with simple name given by expression, and rename it to rename-expression, which is a simple name (not a full path), hence keeping the renamed file in in the same source directory.
i.e.: for file "example.txt" in /sourcepath to be renamed to "example.txt.done" they would be:
remote-directory-expression = /sourcepath
expression = example.txt
rename-expression = example.txt.done
Current Behavior expression must be a full path, as well as rename-expression, while remote-directory-expression seems to be simply ignored. This causes the above to lead to a "file does not exist" error.
In org.springframework.integration.file.remote.gateway.AbstractRemoteFileOutboundGateway.doMv(Message<?>) (I'm using Spring Integration 5.4.11) I see this:
remoteDir is null, because it tries to extract the path by removing the remoteFileName from remoteFilePath (ignoring my remote-directory-expression)
remoteFileNewPath is example.txt.done
Perhaps, if that code used remote-directory-expression in case remoteDir is null, and possibly concatenate that remoteDir with remoteFileNewPath in case the latter is not a full path, could bring the desired result without breaking backward compatibility.
Context
I'm trying to rename a file I have previously read with a <int-sftp:inbound-streaming-channel-adapter> on transaction commit. The inbound adapter only allows for file deletion after read, not file rename/move, and I'm not sure whether the action is executed immediately after reading the source file or at the end of the flow if no exception is got back by downstream components (as I want in my case).
Anyway, in my case I would like to just add a suffix to the file name, without moving it anywhere, so I'd like to limit processing as much as possible, in particular to avoid to make concatenations just to reference a file for which I already know both the remote directory and its simple file name.
Unless I'm missing a better way to do this, the alternative way to achieve this right now is to write the following (which seems a bit ugly to me):
Fixes#3647
To simplify a source and renameTo remote file expressions, the `remoteDirectoryExpression`
is consulted now, when they are not full paths.
This is useful when we want just to rename a remote file in some dir
I must say that the documentation for the SFTP outbound gateway is a bit confusing to describe which attribute does what with the different commands, at least this is my humble feeling. Today I had to go by trial and error and debug to make a recursive mget work as desired. I may open a new documentation issue for that, anyway from what I read I suspect that an enhancement similar to this one could be made for the rm command as well (remote directory + simple file name instead of full path to the file to delete).
Re. rm. I don't feel like we are going to gain something from two expressions configuration instead of one. Since both of them can be combined in a single one anyway, even if both dir and file are dynamic in our flow logic.
But still: since you expressed your concern, I won't mind to make that change, too.
Let's see if @garyrussell is OK with adding this to an open PR or better to address it separately.
* GH-3647: Use remoteDirExpression in MV command
Fixes#3647
To simplify a source and renameTo remote file expressions, the `remoteDirectoryExpression`
is consulted now, when they are not full paths.
This is useful when we want just to rename a remote file in some dir
* * Add JavaDoc for `getDirectoryExpressionProcessor()`
* Fix language in docs
Expected Behavior
I would like to do something like this (I'm using SFTP, but I think this is common to other remote file gateways):
That is: consider the file located under
remote-directory-expression
, with simple name given byexpression
, and rename it torename-expression
, which is a simple name (not a full path), hence keeping the renamed file in in the same source directory.i.e.: for file "example.txt" in /sourcepath to be renamed to "example.txt.done" they would be:
remote-directory-expression
= /sourcepathexpression
= example.txtrename-expression
= example.txt.doneCurrent Behavior
expression
must be a full path, as well asrename-expression
, whileremote-directory-expression
seems to be simply ignored. This causes the above to lead to a "file does not exist" error.In
org.springframework.integration.file.remote.gateway.AbstractRemoteFileOutboundGateway.doMv(Message<?>)
(I'm using Spring Integration 5.4.11) I see this:By debugging I see that:
remoteFilePath
is example.txtremoteFilename
is example.txt as wellremoteDir
is null, because it tries to extract the path by removing theremoteFileName
fromremoteFilePath
(ignoring myremote-directory-expression
)remoteFileNewPath
is example.txt.donePerhaps, if that code used
remote-directory-expression
in caseremoteDir
isnull
, and possibly concatenate thatremoteDir
withremoteFileNewPath
in case the latter is not a full path, could bring the desired result without breaking backward compatibility.Context
I'm trying to rename a file I have previously read with a
<int-sftp:inbound-streaming-channel-adapter>
on transaction commit. The inbound adapter only allows for file deletion after read, not file rename/move, and I'm not sure whether the action is executed immediately after reading the source file or at the end of the flow if no exception is got back by downstream components (as I want in my case).Anyway, in my case I would like to just add a suffix to the file name, without moving it anywhere, so I'd like to limit processing as much as possible, in particular to avoid to make concatenations just to reference a file for which I already know both the remote directory and its simple file name.
Unless I'm missing a better way to do this, the alternative way to achieve this right now is to write the following (which seems a bit ugly to me):
The text was updated successfully, but these errors were encountered: