This seems to be an issue in 2 areas:
The FTP/SFTP Inbound Adapter will use a AbstractInboundFileSynchronizingMessageSource, which allows you to define an AbstractInboundFileSynchronizer. The AbstractInboundFileSynchronizer is responsible for synchronizing the remote file location with the local-directory. If you don't specify a filter, then all files are taking into consideration.
However, its synchronizeToLocalDirectory() method calls copyFileToLocalDirectory() and if the file with the name already exists, it does NOTHING (Even if the file itself changed).
The second problem is in the AbstractInboundFileSynchronizingMessageSource. While you can specify a filter for retrieving remote files with the local temp directory, you CANNOT specify the filters that are responsible for retrieving the file from the local temp directory.
When AbstractInboundFileSynchronizingMessageSource#receive() is called, it calls fileSource.receive(). BUT its filters are hard-coded by AbstractInboundFileSynchronizingMessageSource#buildFilter() --> AcceptOnceFileListFilter<File>() and RegexPatternFileListFilter(completePattern);
Therefore, even if the remote file with a different timestamp/changed contents makes it to the local-temp-directory, it would still not being picked up.
While you could argue that this is not a bug (We don't handle file-contents changes), it would probably be a useful feature to fix these 2 issues.
This raises some interesting questions for improving filtering strategies - and thus further Jiras:
When detecting duplication/file changes, should we add some other filtering strategies such as filtering based on file hashing? That would allow us to detect file changes more effectively (I understand that this may bot be the best solution for large files)
Also, should we provide Inbound FTP/SFTP Adapter that don't require synchronization to the local file system? For example for security reasons, the remote file shall never touch the hard-disk unencrypted. Rather the remote file is streamed to the local machine and we subsequently route the Stream to downstream components, e.g. an Encrypting Transformer etc. before hitting the metal.