I have recently upgraded from Camel 2.7 to a more recent version. I can confirm that the bug is still in trunk.
In Camel 2.7, there was a generic FileChangedExclusiveReadLockStrategy. This checked the modification time of the file using GenericFile.lastModified. This field was set by SftpComponent#asRemoteFile as file.getAttrs().getMTime() * 1000.
In Camel 2.8 onwards, this behaviour is implemented by SftpChangedExclusiveReadLockStrategy. This incorrectly (to my mind) retrieves the timestamp on line 67 using:
newLastModified = f.getAttrs().getATime();
Taking the atime of the file doesn't make a great deal of sense to me; on a POSIX compliant filesystem, the atime will be incremented every time the file is polled, meaning that this strategy will never be able to mark a file as unchanged. While some filesystems are mounted nowadays as noatime or relatime, the mtime is still absolutely the safest mechanism to determine if something is writing to a target file.
The impact of this bug is that we cannot reliably poll files from a remote SFTP server.