Sounds reasonable.
Feel free to contribute!
Thanks

While implementing this feature, I noticed a logic inconsistency between RemoteFileTemplate and AbstractRemoteFileOutboundGateway.

RemoteFileTemplate.send() performs this validation:

private String send(Message<?> message, String subDirectory, FileExistsMode mode) {
	Assert.notNull(this.directoryExpressionProcessor, "'remoteDirectoryExpression' is required");
	Assert.isTrue(!FileExistsMode.APPEND.equals(mode) || !this.useTemporaryFileName,
			"Cannot append when using a temporary file name");

However, AbstractRemoteFileOutboundGateway.setFileExistsMode() automatically changes settings:

public void setFileExistsMode(FileExistsMode fileExistsMode) {
	this.fileExistsMode = fileExistsMode;
	if (FileExistsMode.APPEND.equals(fileExistsMode)) {
		this.remoteFileTemplate.setUseTemporaryFileName(false);
	}
}

This seems problematic as it creates a structure where proper assertion validation becomes impossible. I think it would be more appropriate to remove this automatic configuration from setFileExistsMode() and instead clearly document the relationship between these two settings in the API documentation.

However, I'm not sure about the best approach given backward compatibility concerns. What do you think?

where proper assertion validation becomes impossible

I'm not sure what mean.
The RemoteFileTemplate cannot make an assumption about it API usage.
However, the AbstractRemoteFileOutboundGateway is a user of that RemoteFileTemplate and really can make some.
And we have it with that explicit setUseTemporaryFileName(false). when we provide setFileExistsMode.

I might be OK to remove that assumption, but that indeed would be a breaking change for the next 7.0.
We cannot apply it for the current last 6.5 GA milestone.

"where proper assertion validation becomes impossible"

I meant that the assertion in RemoteFileTemplate always passes because setFileExistsMode() automatically sets setUseTemporaryFileName(false).

The reason I'm asking is that I've implemented setFileExistsModeExpression() to resolve the issue. This method needs to parse the existsMode value at runtime for each request. However, if I follow the current pattern of setting setUseTemporaryFileName(false) as done in setFileExistsMode(), it might cause concurrency issues when handling multiple requests with different modes simultaneously.

I thought it might be worth considering removing the automatic setUseTemporaryFileName(false) from setFileExistsMode() to ensure consistent behavior between setFileExistsMode() and setFileExistsModeExpression(). This would also allow RemoteFileTemplate's assertion check to work meaningfully.

If this change is too significant for the current release cycle, are there better alternatives to maintain consistency while adding this feature? I'm looking for ways to safely handle dynamically changing modes at runtime while maintaining API consistency..

I'll go ahead and create a PR with my current implementation so you can review the approach and we can discuss further options!

Right, I see your point now.
While the static setFileExistsMode() is done only once on the configuration phase, so there is no harm to reset the setUseTemporaryFileName as well, the runtime one resolved by the setFileExistsModeExpression is more problematic.
We really cannot mutate the configuration state of the RemoteFileTemplate because of thread safety.

I wonder if something like totally ignore useTemporaryFileName option when FileExistsMode.APPEND would be much robust solution.
This way, even at runtime resolution, we would be safe because we would not look into that option in case of FileExistsMode.APPEND.

@anthologia ,

Let me know what do you think about my last suggestion!
The point is that we are having release next week, so I'd like to have this in.
Thanks

@artembilan,

I agree that ignoring useTemporaryFileName when in APPEND mode is a robust solution for thread safety! I didn't know you had a release schedule in mind! I'll submit the PR today. Thank you.